[rabbitmq-discuss] Benchmarks

Sat Oct 20 18:53:42 BST 2007

Matt

> I'm evaluated RabbitMQ for a distributed computing project and was
> wondering if anyone had benchmarks regarding non-persistent
> non-transactional messages.

Yes we have.

We have tested RabbitMQ quite a bit and continue to find ways to make
it faster, especially in clustered mode which we have tested with up
to 16 nodes.  I provide a snapshot of several scenarios below.

1) On an older and slower version of RabbitMQ we were able to achieve
166,400 messages per second, with each message being 500 bytes in
size.  The rate is an egress rate (ie "output messages per second").
This was for a pub-sub scenario with one producer and 64 consumers.
Please note when I say pub/sub I mean "1-many" but implemented using
TCP unicast and not UDP multicast.

There were four 2-way AMD machines in the cluster.  I can check for
more info on exactly which model of CPU these were, but they were not
especially recent or fast.

2) The same cluster was able to run with an egress rate of 224,000
messages per second with smaller messages.  When only one machine was
used, the rates in both 500 byte and 12 byte cases were around 65,000
mps (egress).

3) On the current version of RabbitMQ we measured an input rate of
80,000 mps for 256 byte messages, and an output rate of 320,000 mps.
Note this means each published message is replicated four times
instead of 64 as in the previous case.  Also, this was using 16 cores.

Anyway, the total message rate (ingress+egress) was 400,000 mps for
256 bytes per message.  For various reasons we believe we can get much
higher throughputs by tweaking the broker's design - please let us
know if you want to discuss this.

Here are some other factors to consider:

One issue is that different numbers of producers and consumers lead to
different message rates.  We think 1:64 is a good ratio for (say) a
trading floor.  The case we tested in (3) had a ratio of 1:4 for very
specific reasons to do with the use case.  Designing a system that can
cluster to 10s or 100s of nodes while keeping latency reasonable, for
multiple different use cases and pub/sub ratios, is an interesting
challenge as I am sure you appreciate.

Also note that a problem with testing message rates like the ones I
quote above, is that you run into the limits of the network.  We've
been testing using full TCP/IP stacks over 1GigE.  Of course this
means we flood the network with message rates as described above.  In
addition to any speed up due to design, I would expect RabbitMQ to
perform better if able to take advantage of Infiniband for example.

> The FAQ talks about persistant messages:
>
> "From our testing, we expect easily-achievable throughputs of 4000
> persistent, non-transacted one-kilobyte messages per second (Intel
> Pentium D, 2.8GHz, dual core, gigabit ethernet) from a single RabbitMQ
> broker node writing to a single spindle."
>
> but I'd have to imagine that the throughput for non-persistent messages
> per second is significantly higher.  OpenAMQ claims 100k+ non-persistent
> messages per second.
>
> Can anyone provide information regarding the throughput of
> non-persistent non-transactional messages?  Please provide the hardware
> in your responses.

I hope I have answered your questions.  If you need more info on
anything, eg on the exact hardware, please let us know.

To be quite honest I am not sure who would need more than a few 100k
messages per second in 2007, outside of people trading off financial
feeds.  I hope it is enough for your use case.

alexis

>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>

-- 
Alexis Richardson
+44 20 7617 7339 (UK)
+44 77 9865 2911 (cell)
+1 650 206 2517 (US)