[rbranson]

Given the same semantics, RabbitMQ pushes 100k+ per core as well. It utilizes multi-core machines quite effectively too. Obviously as you tune nobs for more durability or reliability, you're going to take a performance hit. IMHO, Redis is a good tool for messaging if you already use Redis in a big way and don't need reliable delivery or any of the advanced AMQP routing. In sort of the same way a table in MySQL can be used as a queue if you already have a MySQL server and you're only going to be pushing a few hundred messages per minute.

[ezmobius]

I call BS on rabbit pushing 100K messages per core and I really like rabbit. But it is no where near 100k messages/sec per core.

AMQP does have extra capabilities and is a good messaging system and has advanced routing features, but you need to learn what exchanges, queues and bindings are and how they relate before it is useful.

I've used rabbit in production on multiple systems and it is still running on some of those. But I have switched to redis for most of my messaging needs because of the built in data structures and persistence. It makes it a much more versatile server and it is much easier to admin and much more stable. Rabbit is too easy to push over when you run it out of memory.

But I had to chime in and refute your 100k messages per core on rabbit. 20k maybe with the java client, more like 5-7k with a ruby or python client.

I can still get 80k/sec with a ruby client on redis.

The two servers are very different, redis is a swiss army knife of data structures over the network, that is why it is so useful. AMQP and rabbit are targeted more at enterprise messaging and integration where raw speed doesn't matter as much as complex hierarchies of brokers and middleware.

[foobarbazetc]

We do 120K messages per core per second with QPid (RHM), which includes an AIO transactional journal and multi-master clustering. Woo. :)

[moe]

Given the same semantics, RabbitMQ pushes 100k+ per core as well.

Until it grinds to a halt for no obvious reason</snark>

We've dropped RabbitMQ on a project a while ago not for performance but for stability and opacity reasons.

I went into detail about the issues in a post a few months ago so I'll skip that here. My take-home is that unless you have complex routing requirements that can only be realized with AMQP then you should think long and hard if you really want the aircraft carrier of a component that is RabbitMQ in your dependency list.

Redis/Resque, beanstalk and Celery cover the overwhelming range of use-cases just fine and are complete no-brainers to operate in contrast to wrestling with AMQP topologies, flakey client libraries and an opaque (to most) erlang blackbox.