Increased 'I/O other bytes' with IIS hosting after porting to .NET Core
- 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
Assessment
This issue has not been assessed yet.