[rabbitmq-discuss] Suggestion for performance options

Wed Jul 16 15:28:06 BST 2008

Hi,

Afte playing with the Multicast test I wanted to share something and 
suggest an improvement to the client connection setup.

By default the MulticastMain test blasts many empty messages over the 
wire, and I was puzzled by the numbers I got. While the machine running 
the broker is "only" an old single-core 2.4GHz P4 (client is a dual-core 
Thinkpad with Windows) I expected much more than ~2000 messages/sec over 
Gigabit ethernet. Turns out that the Java client by default does not set 
any socket buffer options, which are crucial for TCP performance. This is 
usually only a problem over long distances and WANs with large latencies, 
but the situation is essentially the same with many small messages on a 
LAN - just the scales are different.

A quick test confirmed this. I added the following bits to 
SocketFrameHandler's constructor after the socket has been created:

     _socket.setSendBufferSize(16777216);
     _socket.setReceiveBufferSize(16777216);

This resulted in a jump from ~2000 messages/sec to >35000 for the 
producer. Variations with e.g. multiple consumers show similar gains with 
continous receives in the ~20k/sec range.

Now, that 16M value is just an almost arbitrary "big value" for gigabit 
LAN; you might get similar results with something like ~2-4 MB, and in 
fact too large values often degrade performance again (it's all very 
obscure). Both Linux and Windows are supposed to have auto-tuning for the 
TCP stack including dynamically growing the TCP window, but in practice 
this only seems to work in special cases and/or for continuously high 
bandwidth transfers like FTP.

It seems to me that being able to set these values would be a good 
addition to the ConnectionParameters class. They could then be configured 
on the underlying socket when it is created by the ConnectionFactory.

cheers!
Holger