RabbitMQ High-speed Transient Messaging Performance

Kimi picture Kimi · Jan 23, 2010 · Viewed 7.6k times · Source

The system we are building is receiving data through the external feed. Our job is to distribute this data to multiple services, run the calculations and forward the results elsewhere - typical publisher-subscriber situation. What we need is a very low latency messaging. We don't need to persist the messages like MSMQ.

Is RabbitMq fast enough for a soft realtime message delivery? Are there any benchmarks? Is it a good idea to use it instead of TIBCO Rendezvous? Are there any other open-source soft real time messaging alternatives?

Thanks.

Answer

Tony Garnock-Jones picture Tony Garnock-Jones · Jan 25, 2010

(I am a rabbitmq developer.)

Rabbit will, when lightly loaded, generally have latencies on the order of 100-400 microseconds, depending on things like your network card and CPU speed. Once the loading gets a little heavier, internal buffering starts to appear and latencies rise a little. You can safely expect 1ms latencies until the bandwidth use (messages-per-second, bytes-per-second) starts to get high. Latencies will also rise once persistence is introduced, naturally.

Regarding benchmarks, one of the biggest problems here is defining what's important to your application. There are some trivially simple point-to-point and pub-sub latency-and-throughput measuring examples included with the Java client; ask on the rabbitmq-discuss list if you have problems with them! They don't measure much of relevance to real-world applications, but might help allay any concerns you have regarding microbenchmarks of latency or throughput.

Finally, there are many, many good open-source messaging and messaging-related systems available these days. In the world of AMQP alone, besides RabbitMQ, there are also Qpid and OpenAMQ. There are also good open-source JMS servers out there, if you are able to restrict yourself to Java (many people have success with ActiveMQ). Lots of light-weight systems are springing up for Ruby and Python systems, as well; these systems tend to concentrate on queueing alone, and tend not to have the flexible routing capability that AMQP offers.