FileBufferingReadStream CopyToAsync Performance problem.

[avparuch]

When buffering a response using FileBufferingReadStream: initially, the stream's Position and Length are both 0. Based on the code in https://github.com/dotnet/runtime/blob/master/src/libraries/System.Private.CoreLib/src/System/IO/Stream.cs#L160-L188, CopyToAsync chooses a buffer size of 1.

When the stream is say, 16KB, this triggers a FileStream.GetLengthInternal() call 16,384 times and causes a big CPU spike for requests that are buffered to disk.

Please see attached profiler trace.

We are currently solving this issue by calling the overload of CopyToAsync that accepts an explicit buffer size (we chose 16KB).

[Tratcher]

For reference, CopyToAsync is being called as a simple way to fully buffer the data.

We have a DrainAsync extension that can also be used for this (but we should still fix CopyToAsync).

aspnetcore/src/Http/WebUtilities/src/StreamHelperExtensions.cs

Line 15 in 425c196

public static Task DrainAsync(this Stream stream, CancellationToken cancellationToken)

Fixing this is tricky, the Stream.CopyToAsync code that does this check isn't virtual. We may have to talk to the runtime team about how FileBufferingReadStream implements CanSeek, Length, etc..

[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.