Follow up HTTP/2 items

[davidfowl]

There were a couple of follow up items as a result of changing how HTTP/2 output writing works #30235.

• - We need to follow up on how this affects large writes. There will be a task allocation after 4K writes because the ConcurrentPipeWriter allocates a task per pending write. We might also want to use a bigger pause threshold (65K?)
• - We need to determine if we want CompleteAsync to not lie and instead wait on the response to be flushed. Right now it lies and queues other operations after the response is completed. This is more efficient but makes it hard to observe exceptions. This would slow down gRPC scenarios a bit more.
• - Move HPack encoding out of the write lock HTTP/2 output processing make over #40925 (comment)
• - Write window updates in an async code path (

  aspnetcore/src/Servers/Kestrel/Core/src/Internal/Http2/FlowControl/StreamInputFlowControl.cs

  Line 60 in 1b02b85

  _ = _frameWriter.WriteWindowUpdateAsync(StreamId, streamWindowUpdateSize).Preserve();

  and

  aspnetcore/src/Servers/Kestrel/Core/src/Internal/Http2/FlowControl/StreamInputFlowControl.cs

  Line 93 in 1b02b85

  _ = _frameWriter.WriteWindowUpdateAsync(0, connectionWindowUpdateSize).Preserve();

  )

[JamesNK]

We need to determine if we want CompleteAsync to not lie and instead wait on the response to be flushed. Right now it lies and queues other operations after the response is completed. This is more efficient but makes it hard to observe exceptions. This would slow down gRPC scenarios a bit more.

FYI gRPC only uses CompleteAsync when a deadline (i.e. timeout) happens. Perf isn't important there.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
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 .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.