In the last post we covered what flow control is, both as a general concept and the various flow control mechanisms available in RabbitMQ. We saw that publisher confirms and consumer acknowledgements are not just data safety measures, but also play a role in flow control. 

In this post we’re going to look at how application developers can use publisher confirms and consumer acknowledgements to get a balance of safety and high performance, in the context of a single queue. 

Flow control becomes especially important when a broker is being overloaded. A single queue is unlikely to overload your broker. If you send large messages then sure, you can saturate your network, or if you only have a single CPU core, then one queue could max it out. But most of us are on 8, 16 or 30+ core machines. But it’s interesting to break down the effects of confirms and acks on a single queue. From there we can take our learnings and see if they apply to larger deployments (the next post).

As part of our quorum queue series we’re taking a look at flow control, how it protects RabbitMQ from being overloaded and how that relates to quorum queues.

What is Flow Control?​

Flow control is a concept that has been in computer networking and networked software for decades. Essentially it is a mechanism for applying back pressure to senders to avoid overloading receivers. Receivers typically buffer incoming packets/messages as a way of dealing with a send rate that exceeds its processing rate. But receiver buffers cannot grow forever so either the send rate should only transiently exceed receiver processing capacity (bursty traffic) or the sender must be slowed down (back pressure).

Flow control is a way of applying this back pressure on the sender, slowing them down so that the receiver’s buffers do not overflow and latencies do not grow too large. In a chain of sender/receivers, this back pressure can propagate up the chain to the origin of the traffic. In more complex graphs of connected components, flow control can balance incoming traffic between fast and slow senders, avoiding overload but allowing the system to reach full utilisation despite different numbers of senders, different rates and different load patterns (steady or bursty).

Quorum queues are still relatively new to RabbitMQ and many people have still not made the jump from classic mirrored queues. Before you migrate to this new queue type you need to make sure that your hardware can support your workload and a big factor in that is what storage drives you use.

In this blog post we’re going to take a closer look at quorum queues and their performance characteristics on different storage configurations.

HDD or SSD? One drive or multiple drives?​

The TL;DR is that we highly recommend SSDs when using quorum queues. The reason for this is that quorum queues are sensitive to IO latency and SSDs deliver lower latency IO than HDDs. With higher IO latency, you'll see lower throughput, higher end-to-end latency and some other undesirable effects.

Further down in this post we’ll demonstrate why we recommend this, using various benchmarks with different SSD and HDD configurations.

This is the first part of a series on quorum queues, our new replicated queue type. We'll be covering everything from what quorum queues are, to hardware requirements, migration from mirrored queues and best practices.

Introducing Quorum Queues​

Mirrored queues, also known as HA queues have been the de facto option for years when requiring extra data safety guarantees for your messages. Quorum queues are the next generation of replicated queue that aim to replace most use cases for mirrored queues and are available from the 3.8 release and onward.

In this blog series we’re going to cover the following:

• Part 1 - Understand the need for a new replicated queue type and how it works (this post)
• Part 2 - Why your choice of storage drive matters with quorum queues
• Part 3 - Quorum queues and flow control. Concepts.
• Part 4 - Quorum queues and flow control. Single Queue Benchmarks.
• Part 5 - Quorum queues and flow control. Stress Tests.
• Part 6 - Quorum queues and cluster/VM Sizing (coming soon)
• Part 7 - When and how to migrate from mirrored to quorum queues (coming soon)
• Part 8 - Best practices and gotchas (coming soon)
• Part 9 - Monitoring and admin operations (coming soon)

Due to the uncertainties of the COVID-19 virus, the RabbitMQ Summit team is canceling the Berlin Summit in June 2020. We do still hope that we can proceed with the plans for a summit in November in New York. Check back for updates.

Among other contributions this month, we have resources on using RabbitMQ successfully in a microservices architecture, why you should use messaging in your project with Rabbit and SpringBoot, and many other tips and tricks. So dive in, the water’s fine! And please stay safe, everyone.

This Month in RabbitMQ — February 2020 Recap!

RabbitMQ Summit is coming again! This time, the gathering will be in Berlin on June 9 and the call for proposals (to speak at the event) is open until March 22.

Mark your calendars, brush up on your Deutsch, and buy your tickets for the next chance to immerse yourself in all things RabbitMQ. I’m sure there will be at least a couple of RabbitMQ influencers there, too :)

This Month in RabbitMQ, January 2020 Recap

Introducing TGI RabbitMQ! Inspired by TGI Kubernetes, RabbitMQ engineer, Gerhard Lazu has begun a series of tutorial videos. Tune in at the end of each month for the latest release. In January, Gerhard covered upgrading from 3.7 to 3.8. Star and watch the repository for future episode updates.

Also, be sure to check out the dashboards we’ve published to Grafana. These are a great way to get started with the new Prometheus and Grafana support in 3.8.

This Month in RabbitMQ — December Recap!

Happy new year! 3.8.x has been available for over three months now and we’re seeing a lot of great uptake. This is good news, since the upgrade process is even easier with the addition of feature flags. Keep up the upgrading!

Over at the CloudAMQP blog, you’ll now find videos transcripts of all the RabbitMQ Summit talks. Those are useful if you didn’t make it to the event and want to know what’s in the talk before watching the full 30 minute replay.

Take a look at Observe and Understand RabbitMQ, for example.

We also published a new case study about LAIKA, the animation company that brought you Coraline, The BoxTrolls, and Missing Link. If you are interested in having your use case for RabbitMQ profiled on rabbitmq.com, drop a note in the mailing list or email info@rabbitmq.com.

Based in Portland, Oregon, LAIKA is a premier stop-motion animation company. With award-winning films like Coraline, ParaNorman, The BoxTrolls, Kubo and the Two Strings, and most recently, Missing Link, LAIKA is recognized for its unique aesthetic. Producing films the way LAIKA does is at the intersection of high-tech and analog.

LAIKA's small IT team is passionate about the animation business. "We support the production, making the movie." explained Mahlon Smith, Senior Technologist at LAIKA. The team is behind the scenes, amongst set carpenters, painters, and film directors. "We enable the production as efficiently as possible. Every dollar saved is a dollar we can apply towards the screen."

This sense of fiscal responsibility steers the team towards reusable technologies. Particularly when it comes to integration. With that frugality in mind, the team began looking at RabbitMQ as far back as 2009. What they've learned from using RabbitMQ over the last six years is how to solve more with a flexible messaging backbone.

Last month was a big one for the RabbitMQ community because RabbitMQ Summit happened in London! If you missed the event, or if you were at the event, but missed a session in the other track, all the recordings are now available. Also, be sure to check out our overview blog for an easy-to-digest summary of what’s new in RabbitMQ 3.8.

More new 3.8 features and lessons learned will be covered in an upcoming webinar, by RabbitMQ core team member Gerhard Lazu. Tune in on December 12th!