Rabbitmq - Reasonable performance/scale expectations

I'd be grateful if anyone could point me in the direction of some reasonable scale figures/limitations on rabbitmq (on "average" hardware, fwiw) or post your experience with its performance. I'm trying to get a sense of capacity for number of queues, number of subscribers on queues, performance implications of having hundreds or thousands of listeners on fanout queues, any hard numbers anyone might have running rabbit in a high-capacity environment.

Solution 1:

First of all, you need to understand which items in your list have scaling limits that you might hit, and which do not. Some of this is implementation dependent so it helps to read up on internals, for instance the book RabbitMQ in Action.

The number of queues is limited by your RAM. The number of messages in play, on the other hand, is not limited by RAM because RabbitMQ automatically pages them out to disk. Once I accidentally got almost 8 million messages in play on a development server when I wasn't paying attention.

There is also no limit to message sizes, but you really should think twice if the size of a single message exceeds 512K. I ended up using a memory cache to pass large objects between applications and only sent smaller control messages that included a memcache key. But if you really want to you can send huge JPEG's and binary objects like JAR files as messages.

The number of subscribers is an OS limit because a subscriber needs at least one TCP socket open. Of course that is tunable in most OSes, so your mileage will vary and that is why you have to test your model. I have been using JMETER to load test our web applications and I just discovered this AMQP plugin https://github.com/jlavallee/JMeter-Rabbit-AMQP but have not yet used it. In any case, this is the kind of testing that will quickly tell you what your hardware (or VM config) will reasonably handle.

The only difficult thing that you have is testing large numbers of consumers to the fanout queues. You might also want to compare using a topic exchange instead, with consumers subscribing using a wildcard (*) binding key which achieves the same end result. Try to run this test with as many different machines as you can to make sure that you aren't somehow running into a bottleneck caused by a single server running consumer processes. P.S. that Jmeter plugin looks like it may also be useful to simulate consumers.

Solution 2:

This is not really an answerable question - there are too many factors (the moving definition of "average" hardware, the size of messages in the queue, the number of consumers and how often they poll / how quickly they complete work in messages, etc.). You really need to benchmark your environment.

That said, check out some of these discussions of RabbitMQ performance (including some ideas on how you can benchmark your installation to see what you can expect out of Rabbit):

• http://hiramchirino.com/blog/2011/12/stomp-messaging-benchmarks-activemq-vs-apollo-vs-hornetq-vs-rabbitmq/
• http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2011-April/012508.html
• http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2009-October/005177.html
• http://www.rabbitmq.com/blog/2011/10/27/performance-of-queues-when-less-is-more/ (more on tuning)