[rabbitmq-discuss] RabbitMQ Latency
matthias at rabbitmq.com
Mon Aug 20 22:53:17 BST 2012
On 20/08/12 22:09, Emile Joubert wrote:
> On 20/08/12 20:59, Tom Wrigglesworth wrote:
>> In the one the publisher can publish as fast as it likes (within the
>> limits imposed by internal flow control in the broker) while with the
>> other publishing and consuming messages happen in lockstep - that's why
>> it's slower.
>> What do you mean by in lockstep?
> That the total number of messages sent and received differ by at most 1.
How so? In both examples the producer sends a message every 500ms,
modulo node.js scheduler delays.
The wireshark trace Tom submitted in another thread clearly shows a 40ms
delay from the 'publish' going out to the 'deliver' coming back. And
I've reproduced the same result on my machine.
Looking at the trace in more detail though, I can see that the delay is
happening solely on the sending side - between the tcp packet containing
the basic.publish frame and the packet containing the content-header and
Running a similar example with our Java client, all three frames
belonging to a publish get transmitted in a single tcp packet. And the
basic.deliver comes back 0.3ms later.
The difference could be down to Nagle (the Java client disables it by
default; no idea what node-amqp does) or buffer flushing (the Java
client flushes output buffers after complete commands, i.e. at the end
of the three frames in case of a short basic.publish; no idea what
node-amqp does), or some node-amqp/node.js weirdness.
Tom, I suggest you contact the node-amqp authors and/or file a bug.
More information about the rabbitmq-discuss