[rabbitmq-discuss] Low message publish throughput

Wed Jan 26 12:27:01 GMT 2011

Hi Emile,

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.

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.

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?

Thanks for your help,
Cameron Harris

On 26 January 2011 11:36, Emile Joubert <emile at rabbitmq.com> wrote:

>
> Hi Cameron,
>
>
> On 25/01/11 14:42, Cameron Harris wrote:
>
>  I attached a profiler to my publisher and I found that more than 90% of
>> the CPU time was spent calling Flush in WriteFrame (called by
>> BasicPublish). I created an alternate non-flushing code path in the
>> RabbitMQ for BasicPublish, and the publishing speed went up to between
>> 35 000 and 45 000 messages per second, and the messages still got to the
>> client quickly.
>>
>
> I would advise caution when removing the flush. Synchronous methods during
> AMQP connection establishment can timeout and cause failure unless the
> stream is flushed.
>
> 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.
>
>
> Regards
>
> Emile
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20110126/a1d24c5d/attachment.htm>