[rabbitmq-discuss] Latency of publish confirm

[Pierpaolo Baccichet]

Do you happen to already know where the timeout is? I would be happy to
change it on my local repo and run a validation on it


On Tue, Dec 4, 2012 at 8:18 AM, Simon MacMullen <simon at rabbitmq.com> wrote:

> Hi. Yes you are right, there is 25ms of latency sending confirms inside
> the broker when using mirrored queues. I'll file a bug to get this fixed.
>
> Cheers, Simon
>
>
> On 04/12/12 15:16, Pierpaolo Baccichet wrote:
>
>> Found something interesting. I tried to temporarily disable the policy
>> for mirroring of my test queue and now I am consistently getting 7/7.5
>> milliseconds latency. Seems like the issue is triggered by the mirroring
>> of the queue.
>>
>> Pier
>>
>>
>> On Tue, Dec 4, 2012 at 7:11 AM, Pierpaolo Baccichet
>> <pierpaolo at dropbox.com <mailto:pierpaolo at dropbox.com>**> wrote:
>>
>>     Hello Matthias,
>>
>>     Thanks for your quick response!
>>
>>     I double checked the code to make sure that I am not marking
>>     messages as persistent and indeed that's the case. The queues and
>>     the exchanges are marked as durable but the individual messages I
>>     send are not setting the delivery_mode=2.
>>
>>     I am a little skeptical the issue here is sync on disk because
>>     adding producers does not change the behavior. I ran a test with 5
>>     producers sending 10 messages per second each and I am still seeing
>>     exactly the same results. Each producer observes latencies that are
>>     multiple of 31 milliseconds (though based on wireshark capture, this
>>     latency seems to be dominated by the 25 milliseconds we see in
>>     rabbitMQ side). Example output of what I am seeing on the producer
>>     side is below:
>>
>>     1354633782.0697601 - completing send 15 took 63.736915588378906
>>     1354633782.233757 - completing send 16 took 63.80009651184082
>>     1354633782.3976469 - completing send 17 took 63.717842102050781
>>     1354633782.5615449 - completing send 18 took 63.707828521728516
>>     1354633782.725692 - completing send 19 took 63.929080963134766
>>     1354633782.8579049 - completing send 20 took 31.997919082641602
>>     1354633783.0219419 - completing send 21 took 63.837051391601562
>>     1354633783.1538589 - completing send 22 took 31.718969345092773
>>     1354633783.285862 - completing send 23 took 31.77189826965332
>>     1354633783.4498329 - completing send 24 took 63.776016235351562
>>
>>     Also, in my previous email I forgot to specify my environment. I am
>>     running on rabbitMQ 3.0 Erlang R15B02. Python and pika 0.9.8 on the
>>     client side
>>
>>     Pierpaolo
>>
>>
>>     On Tue, Dec 4, 2012 at 1:22 AM, Matthias Radestock
>>     <matthias at rabbitmq.com <mailto:matthias at rabbitmq.com>**> wrote:
>>
>>         On 04/12/12 08:55, Matthias Radestock wrote:
>>
>>             I am guessing your messages are marked as persistent. The
>>             25ms is indeed
>>             an aggregation interval, but for the disk (in particular
>>             fsyncs) rather
>>             than the network.
>>
>>
>>         However, fsyncs also happen when queues and the storage
>>         sub-system go idle, so the interval only kicks in when the
>>         system is busy (thus ensuring that fsyncs aren't delayed
>>         indefinitely).
>>
>>         So I am pretty sure what you are seeing is simply the cost of
>>         performing an fsync per message. There's nothing that can be
>>         done about that except buying faster disks / switching to SSDs.
>>
>>         Regards,
>>
>>         Matthias.
>>
>>
>>
>>
>>
>> ______________________________**_________________
>> rabbitmq-discuss mailing list
>> rabbitmq-discuss at lists.**rabbitmq.com<rabbitmq-discuss at lists.rabbitmq.com>
>> https://lists.rabbitmq.com/**cgi-bin/mailman/listinfo/**rabbitmq-discuss<https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss>
>>
>>
>
> --
> Simon MacMullen
> RabbitMQ, VMware
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20121204/6f84b95d/attachment.htm>