Skip to content

Conversation

@schneems
Copy link
Contributor

@schneems schneems commented Jul 30, 2025

Router 2.0 introduced keepalive support. It will close connections idle after 90 seconds https://devcenter.heroku.com/articles/http-routing#keepalives. We want to avoid a situation where they send a request right before puma closes the connection. We can do that by setting it to the same timeout the router uses + some value (such as 5 seconds).

This timeout is used in the reactor when buffering unfinished request bodies and waiting for new requests on a still open client connection. If a connection is closed incorrectly and doesn't send a TCP FIN this timeout will prevent puma holding onto that connection forever.

There is currently a problem in puma 6x and prior with keepalives that causes high request variance puma/puma#3487. So it's recommended that puma users disable keepalive connections by until that problem is fixed upstream:

$ heroku labs:enable http-disable-keepalive-to-dyno

GUS-W-19166166

Router 2.0 introduced keepalive support. It will close connections idle after 90 seconds https://devcenter.heroku.com/articles/http-routing#keepalives. We want to avoid a situation where they send a request right before puma closes the connection. We can do that by setting it to the same timeout the router uses + some value (such as 5 seconds). 

This timeout is used in the reactor when buffering unfinished request bodies and waiting for new requests on a still open client connection. If a connection is closed incorrectly and doesn't send a TCP `FIN` this timeout will prevent puma holding onto that connection forever.

There is currently a problem in puma 6x and prior with keepalives that causes high request variance puma/puma#3487. So it's recommended that puma users disable keepalive connections by until that problem is fixed upstream:

```
$ heroku labs:enable http-disable-keepalive-to-dyno
```
@schneems schneems requested a review from a team as a code owner July 30, 2025 14:11
@schneems schneems merged commit 534e65d into main Jul 30, 2025
1 check passed
@schneems schneems deleted the schneems/bump-timeout branch July 30, 2025 16:08
edmorley added a commit to heroku/python-getting-started that referenced this pull request Aug 3, 2025
For consistency with the timeout chosen by other languages since #261 landed:
- heroku/heroku-buildpack-php#823
- heroku/ruby-getting-started#190

GUS-W-18319007.

Signed-off-by: Ed Morley <501702+edmorley@users.noreply.github.com>
edmorley added a commit to heroku/python-getting-started that referenced this pull request Aug 3, 2025
For consistency with the timeout chosen by other languages since #261 landed:
- heroku/heroku-buildpack-php#823
- heroku/ruby-getting-started#190

GUS-W-18319007.

Signed-off-by: Ed Morley <501702+edmorley@users.noreply.github.com>
colincasey added a commit to heroku/nodejs-getting-started that referenced this pull request Aug 5, 2025
colincasey added a commit to heroku/nodejs-getting-started that referenced this pull request Aug 5, 2025
yflash3220 added a commit to yflash3220/python-getting-started that referenced this pull request Aug 8, 2025
For consistency with the timeout chosen by other languages since #261 landed:
- heroku/heroku-buildpack-php#823
- heroku/ruby-getting-started#190

GUS-W-18319007.

Signed-off-by: Ed Morley <501702+edmorley@users.noreply.github.com>
@edmorley edmorley removed the request for review from a team August 12, 2025 07:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant