Enable kernel response buffering for HTTP.sys server

[wdls22]

I deploy an ASP.NET Core Service in Service Fabric in Azure.
I tried Kestrel and Http.sys as server and using Response compression.
I found if I use Http.sys as server and usign Response compression, static file download is very slow It will cost more than 1 minutes to doanload a 1.6mb JS file.
If I use Kestrel, this issue will not happen. If I use http.sys without Response compression, it also did not happen.
So maybe something wrong with Http.sys and Response compression?

I tried it on ASP.Net 2.2 and 3.0, it can repro in both environments.

To Reproduce

Building an ASP.NET Core Service with Http.sys as server (using https),
Using "app.UseResponseCompression();" to compress the static file response. Then deploy it to Azure Service Fabric with 5 nodes.

Using browsers to open website. It will take a long time to download static files.
If using Kestrel or Http.sys without compression, it will not happen.
And if I run this service on my local machine, it will never happen Whatever combination.

Screenshots

[Tratcher]

Does it make a difference if you use http vs https?

This is most likely an issue with buffering (or the lack thereof) between response compression and HttpSys. Kestrel has what we call a write-behind buffer for the response body, so most write operations complete immediately and then the server aggregates them on a background thread when writing to the network. HttpSys doesn't do this, every write waits for the data to get fully flushed to the network layer before unblocking the app for the next write. This is mainly a problem if you're doing multiple small writes, you would see lots of small TCP packets on the wire. StaticFiles should be doing fairly large writes though, unless response compression is breaking them up?

Using Wireshark to capture the TCP traffic for HttpSys and Kestrel would be a good place to start. Then we can see how efficiently they're flushing to the network.

[udlose]

any update on this problem?

[Tratcher]

We've had few reports and are not currently investigating this. If you can provide additional details that would help us prioritize it.

Using Wireshark to capture the TCP traffic for HttpSys and Kestrel would be a good place to start. Then we can see how efficiently they're flushing to the network.

[dalir-bajelani]

16KB js file download take 25 seconds to response from server!

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[t-auer]

I have seen a similar behavior a few days ago on Windows Server. Serving Static files with multiple users became very slow. It seems to me that this is due to threadpool starvation (on .net FW 4.8). The number of used threads in the threadpool increased approximately by 1 per second with the server being idle, and after some time there were enough threads that the server started working again.

When using .net core 3.1 I found that requesting 12 static files shows about 70 items completed in ThreadPool when using no compression, but > 3.500 items completed when using compression.

[Tratcher]

Are any active threads blocked on sync IO? That's the usual cause of threadpool starvation.