---
title: "Puma"
description: "2 posts about Puma, summarised, each linking to the original."
---

# Puma
> 2 posts about Puma, summarised, each linking to the original.

## Articles

### [Upgrade to Puma 7 and Unlock the Power of Fair Scheduled Keep-alive](https://yomu.fyi/post/upgrade-to-puma-7-and-unlock-the-power-of-fair-scheduled-keep-alive.md)
- Company: [Heroku](https://yomu.fyi/company/heroku.md)
- Author: Richard Schneeman
- Published: Nov 5, 2025
- Type: Explainer

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.


### [Learn How to Lower Heroku Dyno Latency through Persistent Connections (Keep-alive)](https://yomu.fyi/post/learn-how-to-lower-heroku-dyno-latency-through-persistent-connections.md)
- Company: [Heroku](https://yomu.fyi/company/heroku.md)
- Author: Richard Schneeman
- Published: Nov 4, 2025
- Type: Tutorial

Repeatedly opening TCP connections between the Heroku Router and an application dyno can impose TCP slow start on every request, creating a latency penalty. The post explains how HTTP/1.0 tied each request to a new connection, while HTTP/1.1 keep-alive connections reuse an open connection and amortize setup overhead; unlike pipelining, they do not require requests to be prepared in advance. Heroku Router 2.0 uses keep-alive connections to dynos by default, avoiding repeated slow-start costs on repeat requests and exposing more available bandwidth and lower latency. Ruby applications that previously disabled keep-alives are directed to upgrade to Puma 7.1.0 or newer, then update the bundle, inspect settings, and deploy. Keep-alives still depend on both Puma and router configuration, and the post notes that the router also supports HTTP/2 features.