Repository navigation
Remember the last received HTTP/2 SETTINGS_MAX_CONCURRENT_STREAMS for a given host - #128954
Merged
Merged
Conversation
Co-authored-by: MihaZupan <[email protected]>
…change Co-authored-by: MihaZupan <[email protected]>
…ation Co-authored-by: MihaZupan <[email protected]>
Co-authored-by: MihaZupan <[email protected]>
Copilot created this pull request from a session on behalf of
MihaZupan
June 3, 2026 17:02
View session
MihaZupan
changed the title
Contributor
|
Tagging subscribers to this area: @karelz, @dotnet/ncl |
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates SocketsHttpHandler’s HTTP/2 connection startup behavior to seed a new connection’s initial SETTINGS_MAX_CONCURRENT_STREAMS assumption from the last value observed for the same HttpConnectionPool (host), similar to existing memoization for SETTINGS_MAX_HEADER_LIST_SIZE. This helps avoid over-scheduling streams on freshly created connections when the server enforces a low concurrent-stream limit, reducing refused streams and subsequent retries.
Changes:
- Add per-pool memoization for the last seen HTTP/2
SETTINGS_MAX_CONCURRENT_STREAMS. - Initialize new
Http2Connectioninstances’_maxConcurrentStreamsfrom the pool’s last seen value and update the cached value when processing SETTINGS. - Add a functional test covering the “low max concurrent streams across multiple connections” scenario.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| src/libraries/System.Net.Http/tests/FunctionalTests/SocketsHttpHandlerTest.cs | Adds a functional test intended to validate that the pool remembers low MAX_CONCURRENT_STREAMS across connections. |
| src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/Http2Connection.cs | Seeds initial per-connection max concurrent streams from the pool and records server-advertised values when SETTINGS are processed. |
| src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/ConnectionPool/HttpConnectionPool.cs | Introduces _lastSeenHttp2MaxConcurrentStreams cached per pool (host) with an initial default. |
MihaZupan
reviewed
Jun 3, 2026
Member
|
/azp run runtime-libraries-coreclr outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
ManickaP
approved these changes
Jun 4, 2026
MihaZupan
approved these changes
Jun 4, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The same way we remember the last received SETTINGS_MAX_HEADER_LIST_SIZE for HTTP/2 and 3, we can remember the last server-advertised stream limit.
runtime/src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/ConnectionPool/HttpConnectionPool.cs
Lines 46 to 53 in 291547b
Imagine a scenario where the server advertises a 10-stream limit per connection, and we attempt to send a burst of 100 requests.
Since we limit the number of retries we'll attempt, lots of those requests will end up failing with an error.
After this change though, everything after the first connection attempt will remember that the observed limit was in fact 10, so starting with the 2nd connection we won't try to send more than the 10 streams at a time, avoiding the need to retry anything, and those requests will eventually succeed on new connections.
Without #66944 that might still take a while (opening 10 connections one at a time), but at least the requests won't prematurely fail. Remembering the last value we received is also good to inform whatever heuristic we might end up using for #66944 in the future.