[rabbitmq-discuss] Latency of publish confirm

[Pierpaolo Baccichet]

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>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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20121204/84145963/attachment.htm>