Skip to content

Fix max_keepalive_connections - #1000

Merged
lovelydinosaur merged 1 commit into
encode:masterfrom
blazewicz:blazewicz/fix-max-keepalive-connections
Oct 13, 2025
Merged

lovelydinosaur merged 1 commit into
encode:masterfrom
blazewicz:blazewicz/fix-max-keepalive-connections

Conversation

@blazewicz

@blazewicz blazewicz commented Mar 26, 2025 •

Copy link
Copy Markdown
Contributor

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

  • I understand that this PR may be closed in case there was no previous discussion. (This doesn't apply to typos!)
  • I've added a test for each change that was introduced, and I tried as much as possible to make a single atomic change.
  • I've updated the documentation accordingly.

Comment thread tests/_async/test_connection_pool.py
Comment thread tests/_sync/test_connection_pool.py
@blazewicz
blazewicz force-pushed the blazewicz/fix-max-keepalive-connections branch 2 times, most recently from 0aa2ee1 to 6414fd8 Compare March 29, 2025 18:12

@zanieb zanieb left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
blazewicz force-pushed the blazewicz/fix-max-keepalive-connections branch from 6414fd8 to 7fb2052 Compare September 23, 2025 09:31
@lovelydinosaur

Copy link
Copy Markdown
Member

Ah yeah apologies... this is a nice simple fix, and worth getting in.

@lovelydinosaur
lovelydinosaur merged commit 10a6582 into encode:master Oct 13, 2025
7 checks passed
@springmeyer

springmeyer commented Nov 6, 2025 •

Copy link
Copy Markdown

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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

5 participants