[rabbitmq-discuss] Latency of publish confirm

Tue Dec 4 16:18:16 GMT 2012

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
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>

-- 
Simon MacMullen
RabbitMQ, VMware