dotnet / dotnet/aspnetcore

Increased 'I/O other bytes' with IIS hosting after porting to .NET Core

Open
#32,844 5 comments 0 reactions 0 assignees View on GitHub
area-networking feature-iis investigate
Dominant language
C#
Stars
38.4k
Forks
10.9k
Avg merge
2d 10h
Merged PRs (30d)
281

Description

We noticed a difference in behavior of ASP.NET applications hosted in Internet Information Services (IIS) after porting from .NET Framework to .NET Core. The Windows performance counter _I/O other bytes_ (available as a column in Task Manager) started showing higher values for the same traffic, more than a two-fold increase.

I haven't noticed any negative consequences of this yet, but I think it is worth bringing to your attention, hoping there is an explanation.

Here is a small repro for testing. The code returns a few KB to the caller:

**.NET Core**
```csharp
app.UseEndpoints(endpoints =>
{
endpoints.MapGet("/", async context =>
{
await context.Response.WriteAsync(new string('A', 16 * 1024));
});
});
```

**.NET Framework**
```csharp
[Route]
[HttpGet]
public HttpResponseMessage Index()
{
return new HttpResponseMessage(HttpStatusCode.OK)
{
Content = new StringContent(new string('A', 16 * 1024), System.Text.Encoding.UTF8, "text/plain")
};
}
```
_Remember to disable any compression of dynamic content._

When calling the endpoints above, the ``w3wp`` process will report a different increase of _I/O other bytes_ depending on the runtime and the response length.

| Runtime | Body length | I/O other bytes / request |
| --- | --: | --: |
| .NET Framework | 16 KB | 2 KB |
| .NET Core 3.1 | | ~5 KB |
| .NET Core 5.0 | | ~11 KB |
| .NET Framework | 64 KB | 2 KB |
| .NET Core 3.1 | | ~60 KB |
| .NET Core 5.0 | | ~60 KB |
| .NET Framework | 128 KB | 2 KB |
| .NET Core 3.1 | | ~128 KB |
| .NET Framework | 256 KB | 256 KB |
| .NET Core 3.1 | | ~256 KB |

Notice how the number is the same for .NET Framework up to 256 KB. When the response body is 256 KB or more, the increase in _I/O other bytes_ will be roughly the same as the response length and the same in .NET Core 3.1, .NET Core 5.0, and in .NET Framework.

This is with in-process hosting in IIS. The performance counter value hardly increases at all when testing with Kestrel. I have verified that the number of bytes transferred over the network is as expected.

This is the performance counter description:

> The number of bytes transferred in input/output operations generated by a process that are neither reads nor writes, including file, network, and device I/Os. An example of this type of operation would be a control function. I/O Other Bytes directed to CONSOLE (console input object) handles are not counted.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.