Learn How to Lower Heroku Dyno Latency through Persistent Connections (Keep-alive)

Summary

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.

Takeaways

1. 1

   HTTP/1.1 keep-alive connections reuse an existing TCP connection, avoiding the connection-start portion of TCP slow start for later requests.

2. 2

   Heroku Router 2.0 uses keep-alive connections to dynos by default, but Puma and router configuration can still disable them.

3. 3

   The upgrade path for affected Ruby applications is Puma 7.1.0+, followed by bundle updates, configuration checks, and deployment.