[rabbitmq-discuss] Simple benchmark and results
matthias at lshift.net
Wed Oct 21 08:42:28 BST 2009
David Glaubman wrote:
> For Rabbit, in remote case, client CPU load peaks at around 40%
> (2 cores at a little almost 60%, other 2 < 10%).
> Server CPU load goes to around 30%,
> concentrated on two cores(around 60%, 50%, 5%, 5%).
Given that sending is asynchronous, if neither the client or the server
are maxing out a CPU then the network communication would seem to be the
Nagle is the obvious culprit, but both the client and the server disable
Could it be that the Windows firewall or antivirus is getting in the
way? We have seen some very odd behaviour with these two. OTOH, that
should affect the Java client too. Hmm.
> The Java client tells a very different story ...
> ./runjava.bat com.rabbitmq.examples.MulticastMain -h ca1tesla1 -x 1 -y 1
> -z 20 -s 24 -a
> (Single Publisher, single consumer each on its own thread)
> Averaged 20K/sec sends, 20K/sec receives. All server CPUs were at 85-95%,
> client CPUs at 35%,
> avg reported latency around 8 or 9 ms.
These figures are much more in line with what I'd expect to see.
Note that there is one obvious difference to the .net tests: By setting
the "-a" flag the consumers will operate in auto-ack mode, whereas in
the .net code you posted you do an explicit ack. The former is quite a
bit more efficient and may well account for the bulk of the difference
between the .net and java consumer performance. The setting won't affect
the sending side at all though,
The discrepancy between the .net and Java client merits investigation.
Can you package up your test code in a form that makes it
straightforward to run and thus try to reproduce your results? Bonus
points if it is easy to get the test to run under mono.
> If I can come close to saturating Gbit Ethernet using COTS h/w and
> s/w, I'll know I'm on the right track.
Message size has a big impact. Small messages carry a significant
(relative) framing and processing overhead. To get anywhere close to
saturating Gbit Ethernet your message payloads would have to be
substantially larger than 24 bytes. And you'd definitely want to create
multiple streams. Our OPRA testing with Intel two years ago did both
More information about the rabbitmq-discuss