Increase HTTP connection pool minimum to 64#1928
Open
tyrielv wants to merge 1 commit intomicrosoft:masterfrom
Open
Increase HTTP connection pool minimum to 64#1928tyrielv wants to merge 1 commit intomicrosoft:masterfrom
tyrielv wants to merge 1 commit intomicrosoft:masterfrom
Conversation
tyrielv
force-pushed
the
tyrielv/oom-connection-pool-size
branch
from
31d0a0b to
937c6e1
Compare
tyrielv
force-pushed
the
tyrielv/oom-connection-pool-size
branch
from
937c6e1 to
5e2e15c
Compare
mjcheetham
reviewed
Apr 2, 2026
Member
mjcheetham
left a comment
mjcheetham
left a comment
There was a problem hiding this comment.
64 feels way too high and we run a risk of exhausting ports especially on a machine with multiple enlistments mounted simultaneously.
One thought, do we want to move to a 'lease and return' pool model? (There's a generic ObjectPool we could leverage already.)
Pools like this maintain a set of resources, but when a request for another comes in when all existing resources are 'loaned out' then the pool will mint a new resource, or grow the pool - do we want to look at a dynamic pool size?
Shrinking back to the default again after some period of being below the threshold, or when enough resources are returned. Obviously this is a bigger change than just up-ing a semaphore's static limit.
The connection pool was previously sized to Environment.ProcessorCount (e.g., 8
on an 8-core machine). HTTP object downloads are I/O-bound, not CPU-bound, so
CPU count is a poor proxy for optimal connection concurrency. Under burst
workloads like git checkout, connections saturate almost instantly.
Set the default to 2x ProcessorCount. This provides more headroom during burst
object download scenarios without being overly aggressive for machines with
multiple mounts.
The pool size can be overridden via git config:
git config gvfs.max-http-connections <value>
Any positive integer is accepted. The semaphore is adjusted in-place (via
Release/Wait) rather than replaced, so in-flight requests always release
permits to the correct instance.
Work item: 60167591
Assisted-by: Claude Opus 4.6
Signed-off-by: Tyrie Vella <tyrielv@gmail.com>
tyrielv
force-pushed
the
tyrielv/oom-connection-pool-size
branch
from
5e2e15c to
43ff0ed
Compare
KeithIsSleeping
approved these changes
Apr 2, 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 join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Problem
The connection pool was sized to
Environment.ProcessorCount(e.g., 8 on an 8-core machine). HTTP object downloads are I/O-bound, not CPU-bound, so CPU count is a poor proxy for optimal concurrency. During burst workloads or with many external processes accessing files through ProjFS, smaller connection pools can quickly saturate.Change
Sets a floor of 64 connections by default:
Math.Max(Environment.ProcessorCount, MinConnectionLimit). No-op on machines with >64 cores.Adds a configuration option to override
Key review areas
Testing
No new tests (static initialization). Full test suite (695 tests) passes.