[rabbitmq-discuss] Simple benchmark and results

[Matthias Radestock]

David,

David Glaubman wrote:
> Hi, I am experimenting with RabbitMQ (v1.7.0) on Windows using the .Net
> client.
> [...]
> Client machine: Quad CPU @ 2.4Ghz, 4Gb memory, running 32-bit Windows XP SP2
> Server machine: Quad CPU @ 2.2GHz, 4Gb memory, running 64-bit Windows Server
> 2008 Standard
> Network: 1Gbps Ethernet, tracert shows 2 hops between machines
> [...]
> Benchmark consists of 
> 	1. BasicPublish of 1000 24-byte messages to a Fanout exchange
> (non-persistent)
> 	2. Dequeuing these 1000 messages using a QueueingBasicConsumer
>       3. Sending 1000 24-byte messages using MSMQ
>       4. Receiving 1000 24-byte messages using MSMQ
> (All benchmarks were run using MeasureIt, a free microbenchmarking tool for
> .Net code.)
> 
> Results
> -------
> RabbitMQ:
> In the local case, published about 4K messages per second, consumed about
> 10K messages per second.
> In the remote case, median times were the same as for local, but big
> outliers occurred on some runs.
> (Using BasicGet instead of QueueingBasicConsumer, I got around 1500 messages
> per sec remote, 3K local)
> 
> MSMQ:
> In the local case, MSMQ sent about 40K messages per second, received about
> 40K messages per second.
> In the remote case, MSMQ sent about 33K messages per second, received about
> 1.2K per second.

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

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.

We and other users have seen much higher message rates from RabbitMQ on 
similar hardware than what you are reporting - not quite matching MSQM 
perhaps, but close.

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

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


Regards,

Matthias.