HttpClient creates Quic threads even if HTTP/3 is not in use

[wfurt]

1. Create simple console app with HTTP and run simple http1.1 request on Windows 11 or Server 22.
2. look at application threads.

Application crates 2x threads per core even if HTTP/3 and Quic are not in used. This was originally reported on legacy system with 54 cores. That will create 100+ threads ... for nothing.

We should figure out how to make Quic.IsSupported cheap and defer thread creation until needed.
This will impact legacy app that has no clue tor intention to use Quic or HTTP/3.

[ghost]

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

Issue Details

---

1. Create simple console app with HTTP and run simple http1.1 request on Windows 11 or Server 22.
2. look at application threads.

Application crates 2x threads per core even if HTTP/3 and Quic are not in used. This was originally reported on legacy system with 54 cores. That will create 100+ threads ... for nothing.

We should figure out how to make Quic.IsSupported cheap and defer thread creation until needed.
This will impact legacy app that has no clue tor intention to use Quic or HTTP/3.

Author:	wfurt
Assignees:	-
Labels:	tenet-compatibility, area-System.Net.Quic
Milestone:	-

[rzikm]

I think we can simply try opening and closing the API registration (that should deallocate the internal MsQuic threadpool), and then lazily reopen it when we actually intend to use it.

[ghost]

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

Issue Details

---

1. Create simple console app with HTTP and run simple http1.1 request on Windows 11 or Server 22.
2. look at application threads.

Application crates 2x threads per core even if HTTP/3 and Quic are not in used. This was originally reported on legacy system with 54 cores. That will create 100+ threads ... for nothing.

We should figure out how to make Quic.IsSupported cheap and defer thread creation until needed.
This will impact legacy app that has no clue tor intention to use Quic or HTTP/3.

Author:	wfurt
Assignees:	-
Labels:	area-System.Net.Http, tenet-compatibility, area-System.Net.Quic
Milestone:	7.0.0

[karelz]

Triage: This contributes to 1MB per core Working set regression on Windows 2022/Win11+ and on Linux when msquic is present.
We should fix it in 7.0.

[rzikm]

I talked with Nick in MsQuic discord about this, MsQuicOpenVersion will allocate threads for handling UDP sockets, this is being made lazy by microsoft/msquic#3034, and another set of threads is allocated by RegistrationOpen.

One direction they consider moving is allowing applications (in our case, .NET Runtime) completely control the threads/scheduling, but that is distant future.

Closing MsQuic via MsQuicClose after checking for support and later opening it again lazily when needed is currently the best option.

[wfurt]

Is it worth of picking up that change? It seems like we can suppress the ongoing thread cost but we would still create and destroy the threads when checking the version...

[rzikm]

That MsQuic PR is making API changes, which would prevent it from being ported to the release branch.

[rzikm]

Reopening for backport

[karelz]

Based on discussion on the PR: #75330 (comment) ... we believe some fix should happen in 7.0 - either in RC2/GA or in servicing.

[karelz]

Reopening for 7.0 backport (though we may need to wait for more validation in main first).

[karelz]

Open questions:

• Is System.Net.Http.Functional - HTTP/3 timeouts (mostly on NativeAOT) #75493 regression caused by unloading msquic and will this change address it?
• CR feedback - take another look if we can avoid touching msquic more - [release/7.0] Unload MsQuic after checking for QUIC support to free resources (#75163) #75330 (comment)
  • Will be discussed in team meeting with @stephentoub in presence

[karelz]

Fixed in main (8.0) in PRs #75163 and #75441 and in 7.0 (GA) in PR #75521 and in 6.0.15 in PR #80785.

[karelz]

We have customers impacted on 6.0 as well - only via Kestrel. Reopening for 6.0.x backport.

[ManickaP]

Closing as #80785 is merged

[karelz]

Fixed also in 6.0.15 in PR #80785 -- see #74629 (comment) for details.