[rabbitmq-discuss] Simple benchmark and results
matthias at lshift.net
Tue Oct 20 07:10:11 BST 2009
David Glaubman wrote:
> Hi, I am experimenting with RabbitMQ (v1.7.0) on Windows using the .Net
> 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
> 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.)
> 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)
> 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.
More information about the rabbitmq-discuss