---
title: "Upgrade to Puma 7 and Unlock the Power of Fair Scheduled Keep-alive"
description: "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."
---

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

[Heroku](https://yomu.fyi/company/heroku) · Richard Schneeman · Nov 5, 2025

**Type:** Explainer

## 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.

## Context

When Puma is overloaded and all threads are busy, Puma 6 and earlier can allow a keep-alive connection to monopolize a thread for up to ten requests, causing other requests to experience substantially higher latency. The behavior originated from an optimization designed for HTTP pipelining and becomes especially relevant during bursts or when web capacity needs to be scaled.

## Approach / What changed

Puma 7 changes request queueing so pipelined and keep-alive requests are placed behind previously accepted work, and adjusts wait\_until\_not\_full to permit interleaving. Its accept loop no longer fully blocks when workers are busy; it slows down in proportion to system load. Puma 7.0 disabled keep-alive fast inline behavior, while Puma 7.1.0 reintroduced it with a safeguard for fairness under overload.

## Takeaways

- Puma 6 and earlier could process up to ten requests from one keep-alive connection consecutively, allowing them to bypass previously accepted requests.
- 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.
- 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.

**Tags:** [Performance](https://yomu.fyi/topic/performance), [Puma](https://yomu.fyi/topic/puma), [Ruby](https://yomu.fyi/topic/ruby)

- Source: [Heroku](https://www.heroku.com/blog/upgrade-to-puma-7-and-unlock-the-power-of-fair-scheduled-keep-alive)
- Source URL: https://www.heroku.com/blog/upgrade-to-puma-7-and-unlock-the-power-of-fair-scheduled-keep-alive
- Ingested by Yomu: 2026-09-10T04:05:09.536Z

[Read original post](https://www.heroku.com/blog/upgrade-to-puma-7-and-unlock-the-power-of-fair-scheduled-keep-alive)