RabbitMQ performance chart


Some Simple Scenarios


This first scenario is the simplest – just one producer and one consumer. So we have a baseline.


Of course we want to produce impressive figures. So we can go a bit faster than that – if we don’t consume anything then we can publish faster.

max publish149910msg/s
This uses a couple of the cores on our server – but not all of them. So for the best headline-grabbing rate, we start a number of parallel producers, all publishing into nothing.
max consume64315msg/s
 Of course, consuming is rather important! So for the headline consuming rate, we publish to a large number of consumers in parallel.

Of course to some extent this quest for large numbers is a bit silly, we’re more interested in relative performance. So let’s revert to one producer and one consumer.

 Now let’s try publishing with the mandatory flag set. We drop to about 40% of the non-mandatory rate. The reason for this is that the channel we’re publishing to can’t just asynchronously stream messages at queues any more; it synchronously checks with the queues to make sure they’re still there. (Yes, we could probably make mandatory publishing faster, but it’s not very heavily used.)
 The immediate flag gives us almost exactly the same drop in performance. This isn’t hugely surprising – it has to make the same synchronous check with the queue.
Scrapping the rarely-used mandatory and immediate flags, let’s try turning on acknowledgements for delivered messages. We still see a performance drop compared to delivering without acknowledgements (the server has to do more bookkeeping after all) but it’s less noticeable.
Now we turn on publish confirms as well. Performance drops a little more but we’re still at over 60% the speed of neither acks nor confirms.
Finally, we enable message persistence. The rate becomes much lower, since we’re throwing all those messages at the disk as well.

Leave a Reply