Connection pool clarification

[GeorgSatyros]

Greetings!
Pardon my inexperience in the matter, but I have a question regarding connection pools and their inner workings.
Let's have the context here be making single requests to many different endpoints, rather than multiple requests to the same one.

About the max_connections AsyncClient parameter, does it regulate how many concurrent connections can be active with the same endpoint or how many requests to different endpoints can be sent at once? What's the best practice for concurrent connections in the context of requesting from a large number of different endpoints?
How does that differ in a sync Client context?

[agammann]

With the default transport, max_connections limits connections across its entire pool, including different origins. It is not a separate limit for each endpoint. The sync Client uses the same pool-wide limit.

I checked this with HTTPX 0.28.1 using two local servers on different ports: with max_connections=1, keeping a streamed response open on the first server made a request to the second server raise PoolTimeout. Once the first response was closed, the second request succeeded. That happened with both Client and AsyncClient.

For many endpoints, reuse one client and set resource limits and the pool timeout for your workload. If you want to limit concurrent tasks rather than connections, use an asyncio.Semaphore around requests too; HTTP/2 can carry multiple concurrent requests on one connection. Also close streaming responses promptly so their connections become available again.