One of the greatest things about RabbitMQ is the community that surrounds it. With open source at its roots, people come together to share their code, their knowledge and their stories of how they’ve deployed it in their projects. At a recent meetup near Nice, France, database engineer Adina Mihailescu shared a presentation on choosing messaging systems. Supported by Murial Salvan’s benchmark comparing ActiveMQ, RabbitMQ, HornetQ, Apollo, QPID, and ZeroMQ, they shared some interesting performance comparisons that we’d like to share with you.
In a single laptop benchmark, Salvan ran four different scenarios in order to obtain some insight on performance of the default setups for these messaging solutions. Each test had 1 process dedicated to enqueuing and another dedicated to dequeuing. The message volume and size ranged from 200 to 20,000 to 200,000 messages and 32 to 1024 to 32768 bytes. Both persistent and transient queues and messages were used.
- Brokers perform much better with fewer, bigger messages.
- Persistence drawbacks appear with big messages, and time on small/medium messages is spent on processing not I/O.
- ZeroMQ’s simple feature-set delivers great performance.
- QPID seems to perform the best when persistence is not used.
- AMQP seems more optimized than STOMP.
- RabbitMQ seems to outperform others by a factor of 3 except for the case of big messages.
Adina’s related presentation is titled, “Messaging Systems—How to make the right choice?” In it, she covers the following:
- What are messaging systems?
- How messaging helps with performance, complexity, scalability, quality, cost-effectiveness, high-availability, and messaging patterns
- Comparison of the Java Message Service API, AMQP, and STOMP with code examples
- Functional and operational requirements
- The benchmark results
In one slide, Adina highlights the benefits of message oriented middleware in the cloud, a SaaS model, and explains how overhead is reduced and scale is introduced with greater simplicity and lower cost when messaging takes place in the cloud. Her examples include Amazon Simple Queue Service, CloudAMQP, and StormMQ. To add commentary to this slide, we’d like to also point out that RabbitMQ is available in the cloud via Cloud Foundry and Pivotal along with MongoDB, Redis, and there is also support for Scala and the Play Framework. With RabbitMQ and Cloud Foundry, there are some pretty cool things worth pointing out:
- You can use Node.js with the Cloud Foundry RabbitMQ service
- In Java, you can use Grails with RabbitMQ on Cloud Foundry or build Spring apps that hook up to the RabbitMQ service
- With Ruby on Rails, you can develop in Ruby or Sinatra via the bunny gem and access RabbitMQ services
- There is a new simulator, video, and open source bits available for RabbitMQ and a how-to article for deploying the RabbitMQ simulator on Cloud Foundry.
More About RabbitMQ Performance
Less than a year ago, we began publishing some information about RabbitMQ’s performance and will summarize it here and begin to build a collection of RabbitMQ performance information.
In part one, we measured performance on a single PowerEdge R610 with dual Xeon E5530s and 40GB of RAM, RabbitMQ 2.8.1 and Erlang R15B with HiPE compilation enabled and the code is available. We showed the difference in send rate, receive rate, and average latency improvements between RabbitMQ 2.7.1 and 2.8.1 due to a capability called internal flow control and significant memory improvements.
In part 2, we outlined how different features affect performance using smaller messages. For a baseline, we showed auto-ack of 44,824 messages per second with one producer and one consumer. Looking at aspects of performance independently, we can publish at 53,710 messages per second with no consumption and consume 64,315 messages per second stand-alone. We shared performance number differences from configuring the mandatory flag and immediate flag impact rates as well as acknowledgements, publish confirms, and message persistence. The diagram below explains how message send rate and bytes rate change with message size—message rates drop with size increases, but the number of bytes sent increases. You can read more about message size and horizontal scale prefetch counts in this portion of the post.
In the article, we go on to publish information for scenarios with large queues and paging—we load and drain 500,000 messages, 10,000,000 messages to show where the bottlenecks occur. There are also other in-depth performance resources on the RabbitMQ blog and you can read over 45 case studies, tutorials, and updates on RabbitMQ at the vFabric Blog.
Of course, in the spirit of community, if you’ve run across any great performance articles on messaging and RabbitMQ, we would love to hear from you and share your stories on this blog. To let us know, leave a comment below and we will contact you.
For more information on RabbitMQ:
- Check out the vFabric RabbitMQ product page
- Learn about the New vFabric Reference Architecture and how RabbitMQ fits
- Download a trial of RabbitMQ
- Read how Rabbit is integrated with over 100 developer tools and platforms
- Check out case studies on how Instagram, HuffingtonPost Live, Roblox, and Indeed.com scale with RabbitMQ.