Add PoolingAsyncValueTaskMethodBuilder to System.Net.Security.SslStream.ReadAsyncInternal()

[davidfowl]

As part of the work to reduce the allocation overhead of websocket reads (and possibly writes), there are 3 state machine allocations that happen per-read remaining in the end to end scenario in ASP.NET Core:

• There are 3 state machine boxes that allocate per operation read
  • Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpRequestStream.ReadAsyncInternal() (Pool the missing ReadAsync state machine aspnetcore#41345)
  • System.IO.Pipelines.StreamPipeReader.ReadAsync.__Core|36_0() (Add ValueTask pooling in more places #68457)
  • System.Net.Security.SslStream.ReadAsyncInternal() <- This one

Ideally, we'd add the PoolingAsyncValueTaskMethodBuilder here to avoid the extra allocation when TLS is involved (which is most of the time these days 😄). This would make our server websocket end to end mostly allocation free on a per operation basis.

PS: The writing size needs to be investigated as well but haven't shown up on many profiles that I've seen (mostly because there hasn't been backpressure).

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

As part of the work to reduce the allocation overhead of websocket reads (and possibly writes), there are 3 state machine allocations that happen per-read remaining in the end to end scenario in ASP.NET Core:

• There are 3 state machine boxes that allocate per operation read
  • Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpRequestStream.ReadAsyncInternal() (Pool the missing ReadAsync state machine aspnetcore#41345)
  • System.IO.Pipelines.StreamPipeReader.ReadAsync.__Core|36_0() (Add ValueTask pooling in more places #68457)
  • System.Net.Security.SslStream.ReadAsyncInternal() <- This one

Ideally, we'd add the PoolingAsyncValueTaskMethodBuilder here to avoid the extra allocation when TLS is involved (which is most of the time these days 😄). This would make our server websocket end to end mostly allocation free on a per operation basis.

PS: The writing size needs to be investigated as well but haven't shown up on many profiles that I've seen (mostly because there hasn't been backpressure).

Author:	davidfowl
Assignees:	-
Labels:	area-System.Net, untriaged
Milestone:	-

Tagging subscribers to this area: @dotnet/ncl, @vcsjones
See info in area-owners.md if you want to be subscribed.

Issue Details

---

As part of the work to reduce the allocation overhead of websocket reads (and possibly writes), there are 3 state machine allocations that happen per-read remaining in the end to end scenario in ASP.NET Core:

• There are 3 state machine boxes that allocate per operation read
  • Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpRequestStream.ReadAsyncInternal() (Pool the missing ReadAsync state machine aspnetcore#41345)
  • System.IO.Pipelines.StreamPipeReader.ReadAsync.__Core|36_0() (Add ValueTask pooling in more places #68457)
  • System.Net.Security.SslStream.ReadAsyncInternal() <- This one

Ideally, we'd add the PoolingAsyncValueTaskMethodBuilder here to avoid the extra allocation when TLS is involved (which is most of the time these days 😄). This would make our server websocket end to end mostly allocation free on a per operation basis.

PS: The writing size needs to be investigated as well but haven't shown up on many profiles that I've seen (mostly because there hasn't been backpressure).

Author:	davidfowl
Assignees:	-
Labels:	area-System.Net.Security, untriaged
Milestone:	-

[davidfowl]

In our HTTPs benchmarks this and #68457 are top allocators. The handshake code has allocations too but I don't think that's worth pooling, at least not yet.

[davidfowl]

Adding more data for this. 20,003 requests serving from hello world. I'd love to see this allocation go away in .NET 7

[antonfirsov]

Triage: we will try to look at this in 7.0

[davidfowl]

I can make this change if you'd like 😃