One of the reasons few security products work well in busy Linux environments is that they amplify performance risk. You’re popular and your backend’s load is skyrocketing? Well, the typical product is just going to collect more data and do more analysis, which amplifies the degradation.
In the real world, one of the key ways everyone deals with being overloaded is by dropping less essential things.
We can do the same thing with ring buffers, which are fixed-size queues that typically drop old data once they fill up. Yet, they rarely get used outside of single-reader, single-writer scenarios, because it’s hard to build something correct that scales to 1-to-many scenarios, never mind many-to-many scenarios.
But, what if we told you, you can have a scalable ring buffer that doesn’t need any locking, and works with multiple readers and multiple writers at the same time? You might say, “there’s no such thing”, except that now there is.
Wait, that rings a bell 🔔
Ring buffers are fixed-size first-in-first-out (FIFO) queues. Fixed size queues that separately track the front and back are a category of algorithm called the circular buffer.
Some people treat the term circular buffer and ring buffer the same. For me, a ring buffer is a type of circular buffer, but one that explicitly drops data when the queue fills up.
That’s not the only option for a circular buffer. For instance:
You can just block until space becomes available. You can grow the backing store. You can just do nothing, except signal an insertion error and let the programmer figure it out.
Ring buffers are more resiliant, since they proactively drop when needed. Typically, it’s the oldest data gets dropped. However, there are ring buffers out there that give the option to drop new data instead.
... continue reading