[rabbitmq-discuss] Simple benchmark and results

[David Glaubman]

Matthias,

> It looks like MSMQ may have some optimisation for the local case - 
> perhaps it bypasses the TCP/IP stack?

Yes, I believe local MSMQ is highly optimized (perhaps using pipes?).
My major interest there was the send rate of 33K messages per second 
that MSMQ managed for the remote case, 
compared  to 4K with Rabbit's .Net client.
It's odd -- MSMQ Send seems to be  8X faster than Rabbit/.Net Publish, 
but MSMQ Receive is 8X slower than Consume!

> As for rabbit, I suspect the main bottleneck is actually the .net 
> client. What's the CPU load like for the client? It may well be maxing 
> out one core.

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%).

> [...]
> If you can, try running some tests with the MulticastMain example that 
> ships with the Java client, for comparison.

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.

If #Publishers and/or #Consumers > 1, 
    all server CPUs were maxed out the whole time, client stayed at 35%.

With #Producers = 2, # consumers = 1,   sends/sec = 30K, rcv/sec = 14K. 

With #Producers = 1, # consumers = 2,   sends/sec = 17K, rcv/sec = 27K 
(both consumers get the same messages)

> Also, note that in your particular test setup the RabbitMQ server will 
> not be able to take full advantage of the multiple cores since there is 
> too little inherent parallelism. 

Is load on the server cores so evenly distributed when using the Java client 
(even with single Publisher, single Consumer) 
largely because sends and receives are running simultaneously on separate
(client) threads? 

> Presumably your intended use case does 
> have more than a single message stream, 
> going from one producer to one 
> consumer; such a configuration will produce higher message rates overall.

Yes.  I'm trying to pipeline a large computation 
which consists of a small number of massively parallel stages. 
Each stage consists of a large number of components 
each of which transform an input stream (from previous stage) 
to an output stream (next stage).
I'm basically looking for a way to send messages fast enough
to prove the concept is workable (or not).
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. (and, contrariwise).

David

-----Original Message-----
From: Matthias Radestock [mailto:matthias at lshift.net] 
Sent: Monday, October 19, 2009 11:10 PM
To: David Glaubman
Cc: rabbitmq-discuss at lists.rabbitmq.com
Subject: Re: [rabbitmq-discuss] Simple benchmark and results

[...]
-- 
View this message in context: http://www.nabble.com/Simple-benchmark-and-results-tp25968960p25986856.html
Sent from the RabbitMQ mailing list archive at Nabble.com.