Setting MinRequestBodyDataRate to null cause slow response time

[garayx]

Describe the bug

Adding Limits.MinRequestBodyDataRate = null configuration to kestrel server will add ~40ms to response time when connection using .net framework client.

This doesn't reproduce when:

• using .net core client.
• both server & client are localhost

To Reproduce

Make sure running the server app on other host then the client app, or access the server app from the client via internet (open 5000 port and use public ip).

1. Download the server side app: WebApplicationServer.zip, extract and open .sln file in VS.
2. Publish and run the WebApplicationServer.exe file.
3. Download the client side app WebApplication1.zip, extract, open .sln file in VS and build the project.
4. Go to line 61 in Controllers/HomeController.cs and change the url variable to the WebApplicationServer app url and run
5. In the running client app, go to the Query page, you should get similar results:

round: 0, elapsed: 459 ms
round: 1, elapsed: 41 ms
round: 2, elapsed: 41 ms
round: 3, elapsed: 41 ms
round: 4, elapsed: 42 ms
round: 5, elapsed: 41 ms
round: 6, elapsed: 41 ms
round: 7, elapsed: 42 ms
round: 8, elapsed: 41 ms
round: 9, elapsed: 40 ms
round: 10, elapsed: 41 ms

Max: 42 ms, min: 40 ms
Last 10 average: 79.09 ms, overall average: 79.09 ms

6. Close WebApplicationServer.exe, open back the WebApplicationServer app in VS.
7. Comment line 20 in Program.cs, publish and run the WebApplicationServer.exe.
8. Go back to the client, refresh the Query page, you should get similar results:

round: 0, elapsed: 149 ms
round: 1, elapsed: 3 ms
round: 2, elapsed: 1 ms
round: 3, elapsed: 1 ms
round: 4, elapsed: 1 ms
round: 5, elapsed: 1 ms
round: 6, elapsed: 1 ms
round: 7, elapsed: 1 ms
round: 8, elapsed: 1 ms
round: 9, elapsed: 1 ms
round: 10, elapsed: 1 ms

Max: 3 ms, min: 1 ms
Last 10 average: 14.64 ms, overall average: 14.64 ms

Further technical details

• ASP.NET Core 3.1.3
• output of dotnet --info

dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   3.1.201
 Commit:    b1768b4ae7

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.18363
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\3.1.201\

Host (useful for support):
  Version: 3.1.3
  Commit:  4a9f85e9f8

.NET Core SDKs installed:
  2.2.207 [C:\Program Files\dotnet\sdk]
  3.1.102 [C:\Program Files\dotnet\sdk]
  3.1.201 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.17 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.17 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.17 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.2 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 3.1.3 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

• The IDE is VS 2019, version 16.5.4

[analogrelay]

using .net framework client.

To be clear, do you mean when using HttpClient on .NET Framework? (cc @stephentoub @karelz since HttpClient seems to be a distinguishing factor; still investigating, but if you have thoughts, chime in :)).

@garayx can you collect a network trace using a tool like Wireshark? That would help us identify possible differences.

[garayx]

To be clear, do you mean when using HttpClient on .NET Framework?

I meant .net framework client side app, but yes all it does is create HttpClient and send single post request.

Please see the wireshark outputs:

• framework_MinRequestBodyDataRate_null.zip This is when MinRequestBodyDataRate = null, we have the ~40ms latency lag.

• framework_MinRequestBodyDataRate_default.zip This is when MinRequestBodyDataRate configuration is default, we don't have the lag.

Also I forgot to mention that we didn't observe the lag prior to upgrading the server side to .net core 3 from .net core 2

[stephentoub]

Might this have something to do with Expect: 100-continue? That header will be sent by default on .NET Framework and not on .NET Core.

[garayx]

I did try to set HttpClient.DefaultRequestHeaders.ExpectContinue = false; that didn't fix the issue.

[ppekrol]

Hi,

any update on this? We are getting more and more reports from our customers that instead of usual low latency on requests around ~10ms, they are now getting the ~50ms. The root cause for all of them is the same, they are using our Client API on .NET Framework, not .NET Core.

[BrennanConroy]

@JunTaoLuo Could you take a look at this?

[ghost]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[ghost]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[BrennanConroy]

Looks like we figured it out, using #30449 to track this issue.