Upgrade to Puma 7 and Unlock the Power of Fair Scheduled Keep-alive

Summary

Puma 6 and earlier could let a keep-alive connection “cut the line” when all threads were busy, allowing up to ten requests from that connection to run consecutively while previously accepted work waited. The behavior came from reusing a “fast inline” optimization intended for HTTP pipelining, where requests arrive together, for keep-alive requests that can arrive later. Puma 7 changes queueing so pipelined and keep-alive requests return to the back of the queue, and adjusts wait_until_not_full so interleaving is possible; its accept loop now slows proportionally with load instead of stopping completely. The fix does not add capacity, but distributes overload delay more fairly across requests. The post recommends upgrading to Puma 7.1.0 or later, especially for applications that had disabled keep-alives after latency spikes.

Takeaways

1. 1

   Puma 6 and earlier could process up to ten requests from one keep-alive connection consecutively, allowing them to bypass previously accepted requests.

2. 2

   Puma 7’s fairness changes make new keep-alive and pipelined requests wait their turn, while the accept loop slows proportionally instead of stopping completely.

3. 3

   The fix does not increase request capacity; under overload, it distributes processing delay more evenly. Applications are recommended to upgrade to Puma 7.1.0 or later.