Puma 7 is here, and that means your Ruby app is now keep-alive ready. This bug , which existed in Puma for years, caused one out of every 10 requests to take 10x longer by unfairly “cutting in line.”  In this post, I’ll cover how web servers work, what caused this bad behavior in Puma, and how it was fixed in Puma 7; specifically an architectural change recommended by MSP-Greg that was needed to address the issue. For a primer on keep-alive connections: what they are and why they are critical for low-latency, performant applications, see our companion post Learn How to Lower Heroku Dyno Latency through Persistent Connections (Keep-alive) Puma 6 Keepalive bug When all threads are busy, Puma 6 and prior incorrectly allow a new keep-alive request to “cut the line” like this: In this image, A is the first request, on a keep-alive connection. After A finishes processing, instead of working on request B , Puma 6 (and prior) incorrectly starts working on C , the next request on the same keep-alive connection.…