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. |