RabbitMQ performance chart

http://www.rabbitmq.com/blog/2012/04/25/rabbitmq-performance-measurements-part-2/

Some Simple Scenarios

auto-ack44824msg/s

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

no-consume53710msg/s

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.

mandatory22402msg/s
 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.)
immediate22035msg/s
 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.
ack32005msg/s
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.
ack-confirm26103msg/s
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.
a-c-persist4725msg/s
Finally, we enable message persistence. The rate becomes much lower, since we’re throwing all those messages at the disk as well.