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<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Dec 4, 2012 at 8:18 AM, Simon MacMullen <span dir="ltr">&lt;<a href="mailto:simon@rabbitmq.com" target="_blank">simon@rabbitmq.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi. Yes you are right, there is 25ms of latency sending confirms inside the broker when using mirrored queues. I&#39;ll file a bug to get this fixed.<br>

<br>
Cheers, Simon<div class="im"><br>
<br>
On 04/12/12 15:16, Pierpaolo Baccichet wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
Found something interesting. I tried to temporarily disable the policy<br>
for mirroring of my test queue and now I am consistently getting 7/7.5<br>
milliseconds latency. Seems like the issue is triggered by the mirroring<br>
of the queue.<br>
<br>
Pier<br>
<br>
<br>
On Tue, Dec 4, 2012 at 7:11 AM, Pierpaolo Baccichet<br></div><div><div class="h5">
&lt;<a href="mailto:pierpaolo@dropbox.com" target="_blank">pierpaolo@dropbox.com</a> &lt;mailto:<a href="mailto:pierpaolo@dropbox.com" target="_blank">pierpaolo@dropbox.com</a>&gt;<u></u>&gt; wrote:<br>
<br>
� � Hello Matthias,<br>
<br>
� � Thanks for your quick response!<br>
<br>
� � I double checked the code to make sure that I am not marking<br>
� � messages as persistent and indeed that&#39;s the case. The queues and<br>
� � the exchanges are marked as durable but the individual messages I<br>
� � send are not setting the delivery_mode=2.<br>
<br>
� � I am a little skeptical the issue here is sync on disk because<br>
� � adding producers does not change the behavior. I ran a test with 5<br>
� � producers sending 10 messages per second each and I am still seeing<br>
� � exactly the same results. Each producer observes latencies that are<br>
� � multiple of 31 milliseconds (though based on wireshark capture, this<br>
� � latency seems to be dominated by the 25 milliseconds we see in<br>
� � rabbitMQ side). Example output of what I am seeing on the producer<br>
� � side is below:<br>
<br>
� � 1354633782.0697601 - completing send 15 took 63.736915588378906<br>
� � 1354633782.233757 - completing send 16 took 63.80009651184082<br>
� � 1354633782.3976469 - completing send 17 took 63.717842102050781<br>
� � 1354633782.5615449 - completing send 18 took 63.707828521728516<br>
� � 1354633782.725692 - completing send 19 took 63.929080963134766<br>
� � 1354633782.8579049 - completing send 20 took 31.997919082641602<br>
� � 1354633783.0219419 - completing send 21 took 63.837051391601562<br>
� � 1354633783.1538589 - completing send 22 took 31.718969345092773<br>
� � 1354633783.285862 - completing send 23 took 31.77189826965332<br>
� � 1354633783.4498329 - completing send 24 took 63.776016235351562<br>
<br>
� � Also, in my previous email I forgot to specify my environment. I am<br>
� � running on rabbitMQ 3.0 Erlang R15B02. Python and pika 0.9.8 on the<br>
� � client side<br>
<br>
� � Pierpaolo<br>
<br>
<br>
� � On Tue, Dec 4, 2012 at 1:22 AM, Matthias Radestock<br></div></div><div class="im">
� � &lt;<a href="mailto:matthias@rabbitmq.com" target="_blank">matthias@rabbitmq.com</a> &lt;mailto:<a href="mailto:matthias@rabbitmq.com" target="_blank">matthias@rabbitmq.com</a>&gt;<u></u>&gt; wrote:<br>
<br>
� � � � On 04/12/12 08:55, Matthias Radestock wrote:<br>
<br>
� � � � � � I am guessing your messages are marked as persistent. The<br>
� � � � � � 25ms is indeed<br>
� � � � � � an aggregation interval, but for the disk (in particular<br>
� � � � � � fsyncs) rather<br>
� � � � � � than the network.<br>
<br>
<br>
� � � � However, fsyncs also happen when queues and the storage<br>
� � � � sub-system go idle, so the interval only kicks in when the<br>
� � � � system is busy (thus ensuring that fsyncs aren&#39;t delayed<br>
� � � � indefinitely).<br>
<br>
� � � � So I am pretty sure what you are seeing is simply the cost of<br>
� � � � performing an fsync per message. There&#39;s nothing that can be<br>
� � � � done about that except buying faster disks / switching to SSDs.<br>
<br>
� � � � Regards,<br>
<br>
� � � � Matthias.<br>
<br>
<br>
<br>
<br>
<br></div><div class="im">
______________________________<u></u>_________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.<u></u>rabbitmq.com</a><br>
<a href="https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">https://lists.rabbitmq.com/<u></u>cgi-bin/mailman/listinfo/<u></u>rabbitmq-discuss</a><br>
<br>
</div></blockquote><span class="HOEnZb"><font color="#888888">
<br>
<br>
-- <br>
Simon MacMullen<br>
RabbitMQ, VMware<br>
</font></span></blockquote></div><br></div>