Track all HttpConnectionPoolManager instances in a global list

[MihaZupan]

I was looking at what events & counters may be useful to add to connection pooling (#66605 (comment)).

For some things, it would be useful to have a reference to every HttpConnectionPoolManager in the process.
Having such a list would make it possible to improve a few things:

• Reduce per-request overhead of tracking stats like http11-requests-in-queue
  • Doing such tracking inline during the request isn't prohibitively expensive though
• Simplify the cleaning & heartbeat timer logic across pools
  • A single timer can be used for the whole process, instead of toggling timers per manager instance
• Simplify the NetworkChange notifications
  • A single notification is sufficient for all managers, avoiding the added logic around the callback registration cleanup
• Potentially simplify other per-pool timer mechanisms (not sure if this is viable yet)
  • Recent example of issues that come along with that: [HTTP/3] HttpConnectionPool may leak authorityExpireTimer / hit ObjectDisposedException #66782
• We avoid tracking some things like http11-connections-current-total when telemetry is disabled. As a result, you will see wrong values if you turn telemetry on later on during the process's lifetime.
  • With a global list, we can always know the correct value

This PR adds such a collection HttpConnectionPoolManager.AllManagers, uses a global timer for cleanup & heartbeats and a single NetworkChange callback.

Cases where this approach may have a higher overhead:

• You have A LOT of SocketsHttpHandler instances that are completely idle (without a single pool)
• You have a lot of handler instances, but your cleaning/heartbeat intervals are really high, making the 1 Hz scanning more expensive

Opening as a draft to gather feedback on whether we think such a change is a horrible idea.

[ghost]

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

Issue Details

---

I was looking at what events & counters may be useful to add to connection pooling (#66605 (comment)).

For some things, it would be useful to have a reference to every HttpConnectionPoolManager in the process.
Having such a list would make it possible to improve a few things:

• Reduce per-request overhead of tracking stats like http11-requests-in-queue
  • Doing such tracking inline during the request isn't prohibitively expensive though
• Simplify the cleaning & heartbeat timer logic across pools
  • A single timer can be used for the whole process, instead of toggling timers per manager instance
• Simplify the NetworkChange notifications
  • A single notification is sufficient for all managers, avoiding the added logic around the callback registration cleanup
• Simplify other per-pool timer mechanisms
  • Recent example of issues that come along with that: [HTTP/3] HttpConnectionPool may leak authorityExpireTimer / hit ObjectDisposedException #66782
• We avoid tracking some things like http11-connections-current-total when telemetry is disabled. As a result, you will see wrong values if you turn telemetry on later on during the process's lifetime.
  • With a global list, we can always know the correct value

This PR adds such a collection HttpConnectionPoolManager.AllManagers, uses a global timer for cleanup & heartbeats and a single NetworkChange callback.

Cases where this approach may have a higher overhead:

• You have A LOT of SocketsHttpHandler instances that are completely idle (without a single pool)
• You have a lot of handler instances, but your cleaning/heartbeat intervals are really high, making the 1 Hz scanning more expensive

Opening as a draft to gather feedback on whether we think such a change is a horrible idea.

Author:	MihaZupan
Assignees:	MihaZupan
Labels:	area-System.Net.Http
Milestone:	7.0.0

[MihaZupan]

/azp run runtime-libraries-coreclr outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).