actix
Streaming response blocks worker from handling other requests while streaming to client
Expected Behavior
Streaming responses will behave like normal responses in regards to connection limits.
Current Behavior
Running streamed responses can make other requests fail, timeout or stall.
My guess is that the streamed response somehow prevents the current worker from handling anymore requests while the response is being streamed. This shouldn't happen since the response is streamed in an async fashion.
Possible Solution
Not sure, but I would suspect some bug in how streamed responses are handled. I highly doubt that this would be intended behaviour.
I searched for the bug and didn't find any record of it. max_connections() and max_connection_rate() is already high and setting both explicitly to 100 didn't change the behaviour at all.
When enough streaming responses are stopped, new request that stalled usually also return a 408 (timed out), which seems to suggest that the request may have technically been started / timed internally to notice the timeout when handling it.
Steps to Reproduce (for bugs)
- Set a low amount of workers (1 or 2)
- Have one or 2 streamed responses running
- Other requests will start to take a while, timeout or stall (connected and new web sockets are also affected)
Context
Using actix-web here to download a large usb image. This download can take long and I noticed that having a download running makes other webpages (partially) unresponsive. Sometimes only websockets stopped connecting, stalled or even simple requests didn't go through as long as the download was running.
I'm using 2 workers as more makes no sense on the target platform (weak singlecore arm cpu). Increasing the amount "fixes" the problem. Running more downloads at once eventually stall the rest again though, making this an easy way to dos the server.
Your Environment
- Rust Version (I.e, output of
rustc -V): rustc 1.63.0-nightly (12cd71f4d 2022-06-01) - Actix Web Version: 4.0.1
- Platform: Was running on armv7, but also does the same on x86_64 (host)
I recently migrated from an old actix 3.X to 4.0.1. I didn't notice this behaviour before, so this might be introduced in the last 2 years (or 3.X -> 4; no guarantee on this).
Below is a video demonstrating the bug manifesting:
https://user-images.githubusercontent.com/22298664/171999815-c3793d3a-17dc-4910-a432-7da9727ef237.mp4
