Hi Emile,<br><br>When I removed the flush, I added an alternate code path so that flushing would only be disabled when called via BasicPublish, and that initiation would still explicitly flush. I initially just commented out the flush, but as you suggested, the connection initiation just failed due to a timeout. Unfortunatey, the problem with just hacking out publish flushing is that sometimes messages will just sit there forever until something forces them out, which could clearly cause a deadlock if your systems ended up waiting on each other. It also caused problems when closing the connection to the broker. I&#39;m guessing that all publish messages need to have been flushed before the library tries to do something else (e.g. a TxCommit or other control messages)? Plus, manually hacking up the RabbitMQ library isn&#39;t really a path I want to go down, since it&#39;ll make upgrading it far more difficult.<br>
<br>I just commented out the line where it sets socket nodelay, and it increased publish to about 9-10k messages per second on the Win7 system, which is a nice improvement. Is there anywhere I can configure this with the standard client library, rather than building my own with it hacked out? The Java client had a way of overriding the socket factory function.<br>
<br>I think the throughput is still being held back significantly by the explicit flushing. It&#39;d still be nice if we could not flush after every publish or manually take control over when publish flushes occur while still maintaining stability of the library/connection. Are there any plans regarding the flushing behavior, or is Rabbit&#39;s primary focus going to be strictly low latency over high throughput? <br>
<br>Thanks for your help,<br clear="all">Cameron Harris<br>
<br><br><div class="gmail_quote">On 26 January 2011 11:36, Emile Joubert <span dir="ltr">&lt;<a href="mailto:emile@rabbitmq.com">emile@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;">
<br>
Hi Cameron,<div class="im"><br>
<br>
On 25/01/11 14:42, Cameron Harris wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I attached a profiler to my publisher and I found that more than 90% of<br>
the CPU time was spent calling Flush in WriteFrame (called by<br>
BasicPublish). I created an alternate non-flushing code path in the<br>
RabbitMQ for BasicPublish, and the publishing speed went up to between<br>
35 000 and 45 000 messages per second, and the messages still got to the<br>
client quickly.<br>
</blockquote>
<br></div>
I would advise caution when removing the flush. Synchronous methods during AMQP connection establishment can timeout and cause failure unless the stream is flushed.<br>
<br>
I&#39;d be interested to know whether disabling the socket nodelay option has any impact on your test. This would be another way of obtaining a different latency/throughput trade-off.<br>
<br>
<br>
Regards<br><font color="#888888">
<br>
Emile<br>
<br>
</font></blockquote></div><br>