Fix max_keepalive_connections - #1000
Merged
lovelydinosaur merged 1 commit intoOct 13, 2025
Merged
lovelydinosaur merged 1 commit into
lovelydinosaur merged 1 commit into
Conversation
blazewicz
commented
Mar 26, 2025
blazewicz
commented
Mar 26, 2025
blazewicz
force-pushed
the
blazewicz/fix-max-keepalive-connections
branch
2 times, most recently
from
March 29, 2025 18:12
0aa2ee1 to
6414fd8
Compare
methane
approved these changes
Sep 3, 2025
zanieb
approved these changes
Sep 22, 2025
zanieb
left a comment
Contributor
There was a problem hiding this comment.
This does seem like a fairly straightforward oversight in the implementation.
This commit fixes a bug in both sync and async connection pools where idle connections were dropped from the pool even when max_keepalive_connections limit has not been reached. This happened because the check compared this number to the total number of connections, not only the idle ones.
blazewicz
force-pushed
the
blazewicz/fix-max-keepalive-connections
branch
from
September 23, 2025 09:31
6414fd8 to
7fb2052
Compare
Member
|
Ah yeah apologies... this is a nice simple fix, and worth getting in. |
|
Will this be released soon in a formal release? Perhaps a 1.0.10? |
gabfssilva
added a commit
to gabfssilva/skyward
that referenced
this pull request
Sep 27, 2026
…'s pool httpcore looks over every request queued on its pool, against every connection it holds, whenever a request comes or goes. A pool that submits two thousand calls at once queued all of them there: in isolation, two thousand requests cost 43 s of CPU queued on the pool and 0.55 s bounded before it. That was the thirteen seconds the SDK saw for requests the daemon answered in milliseconds, and it is filed upstream as encode/httpcore#1035, open and unreleased. `Client._send` now holds one of `SENDS` turns for each attempt, so a request reaches the pool with a connection free for it and the rest wait on a semaphore. A lease renewal still rides the control connections and waits for no turn, and the backoff between retries holds none. The remote pool has `SENDS` connections and keeps every one of them when idle; with httpx's default of twenty kept, it closes any connection that goes idle while it holds more than twenty (encode/httpcore#1000, merged but unreleased). `SENDS` is fifty. Locally, 2000 calls of two seconds on 200 slots, whose ideal is 20 s, ran in 139.7 s before this; after it they ran in 25.6–27.0 s with fifty in flight, 28.0–29.8 s with a hundred, 26.3 s with twenty-five and 29.6 s with two hundred. Submitting is now the daemon's pace — about two hundred a second whatever the bound — and the more it is handed at once, the slower it places the tasks it already has: while the burst lasts it starts some forty-five a second, and a hundred once it ends. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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
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.
Summary
This commit fixes a bug in both sync and async connection pools where idle connections were dropped from the pool even when max_keepalive_connections limit has not been reached. This happened because the check compared this setting's value to the total number of connections, not only of the idle ones.
Checklist