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'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't really a path I want to go down, since it'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'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'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"><<a href="mailto:emile@rabbitmq.com">emile@rabbitmq.com</a>></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'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>