[rabbitmq-discuss] Suggestion for performance options
holger at wizards.de
Wed Jul 16 15:28:06 BST 2008
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:
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.
More information about the rabbitmq-discuss