[rabbitmq-discuss] RabbitMQ Latency

[Matthias Radestock]

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 
content-body frames.

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.

Regards,

Matthias.