14

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.

Martin Schröder
  • 315
  • 1
  • 5
  • 24
user21640
  • 263
  • 1
  • 2
  • 7
  • This is extremely simple to test, especially considering that, with the numbers you're expecting, you have a budget for getting some VMs ready. I highly suggest you test it based on your exact use case, on the hardware you would expect to use. – Andrew M. Apr 10 '12 at 23:15
  • Have a look at the plans of [CloudAMQP](https://www.cloudamqp.com/plans.html) - these are tested performance numbers for certain hardware configurations. – Martin Schröder Jul 06 '16 at 18:35

2 Answers2

12

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.

Michael Dillon
  • 1,809
  • 13
  • 16
6

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):

voretaq7
  • 79,345
  • 17
  • 128
  • 213
  • 1
    I'm aware of the many variables. That's why I mentioned things like "average" hardware, in quotes as I understand how fuzzy an idea that is. Nevertheless I thought some numbers derived from peoples experiences would be useful. Thanks for the references. – user21640 Apr 10 '12 at 20:41
  • 1
    @user21640 It's not just the hardware that adds fuzz to your question - High-Frequency Trading may have a different idea of "high capacity" than you or I do, and vastly different definitions of acceptable performance. Ultimately the only person whose experience matters is you, in your environment, and in my experience one well-planned local benchmark is worth thousands of external reports when it comes to confidence in capacity planning - you never know when your workload is *THE* pathological case :-) – voretaq7 Apr 10 '12 at 21:38