Does the Reactor also transmit responses in addition to buffering requests?

[bbascarevic]

If I understand the docs/architecture.md document correctly, Puma protects from slow clients by employing an async nio reactor that reads requests fully before handing them off to available worker threads for processing. Slow clients won't affect the worker thread pool and the number of concurrent slow clients is probably only limited by the available memory. But once the request is processed and the response needs to be transmitted, is this done by the worker thread or is there a nio reactor that handles transmitting responses to clients at their pace?

Also an additional question, is the entire request, potential large body included, read by the reactor before the handoff with no exceptions?

[nateberkopec]

Responses are not buffered in Puma, so the ThreadPool worker thread will send them to the client directly.

The entire request is read by the reactor unless queue_requests is false.

[Vuta]

Normally people would use Puma behind a reverse proxy like Nginx or Apache, and those proxies have their own mechanism to mitigate this problem too. So, not sure if it's worth implementing these in Puma itself?

[nateberkopec]

We've always supported the "without a reverse proxy" usecase. It's one of the things that makes this project different than, say, Unicorn, which does explicitly say in their Readme that you should use a reverse proxy. It's why we have SSL and request buffering. So, I do think it's something we can support.

[stevenharman]

We've always supported the "without a reverse proxy" usecase.

Yep! And I've always appreciated that. In fact, we're looking to move from an nginx + Unicorn setup to Puma in our Heroku-based deployment. Part of that migration strategy includes mitigating potential thread-safety issues in our code. To do that, we're going to use a Dyno-by-Dyno feature toggle that will boot using Puma in a multi-process, single-threaded mode. Which led me to looking into how Puma handles slow-reading clients, and this discussion. 😄

@nateberkopec Those options make sense to me. My gut-reaction would be option one as it limits the configuration needed to protect against slow-reading clients. But I'm not familiar enough with the technical/implementation tradeoffs of that option to have an opinion.

[nateberkopec]

This is now issue #3110

[stevenharman]

Thank you, @nateberkopec!