[rabbitmq-discuss] Simple benchmark and results

Wed Oct 21 08:42:28 BST 2009

David,

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 
bottleneck.

Nagle is the obvious culprit, but both the client and the server disable 
that.

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 
these things.

Regards,

Matthias.