A connection pool is a bounded resource and a waiting policy

HTTP/1.1 normally supports persistent connections, but the next exchange can be parsed safely only when the previous message's boundary is known. A client must consume the response body or close the connection before reusing it for another request. Servers likewise need to consume a request body or close after responding when unread bytes would remain. Streaming a body keeps ownership live longer than receiving headers alone. A library can hide these details behind a response object, yet the application still needs to drain, dispose, or cancel that object according to the library's documented contract.

An idle connection can be closed by the peer between a local health check and the next write. A pool cannot turn that race into a guarantee that every reused connection remains usable. Keep connection establishment, request transmission, response start, and response completion as separate events when deciding whether a retry is safe. A broken connection after a state-changing request was sent does not prove the server failed to execute it. Reuse policies should therefore cooperate with application idempotency and deadlines rather than automatically replaying every request that encountered an idle-connection error.

For an intentionally simple non-pipelined HTTP/1.1 pool, each connection serves one active exchange at a time. If K connections stay occupied for an average S seconds per request, K/S is an ideal long-run throughput ceiling under stable conditions. It is not a service guarantee, and a tail of slow streaming responses can create substantial acquisition delay. Decide whether the pool limit is per origin, per process, or global. Thousands of callers each owning a small separate pool can still create a large aggregate connection count at the backend.

A bounded active pool with an unbounded acquisition queue simply moves overload into waiting callers. Bound pending requests, account for their memory, and include acquisition time in the end-to-end deadline. Releasing a canceled caller's local wait does not necessarily stop an already transmitted request. Multiplexed HTTP/2 and HTTP/3 change the occupancy unit because a connection can carry many streams, but peer stream limits, flow-control credit, host resources, and backend capacity still constrain concurrency. More connections can also change congestion competition and resource consumption; a faster benchmark does not by itself identify the original bottleneck.

Idle expiry avoids retaining resources indefinitely, while maximum lifetime can encourage eventual connection rotation. Neither should terminate useful work without an explicit policy. Coordinate with load balancers and backend draining so new requests stop using a connection before planned shutdown when possible. Record acquisition wait, occupied and idle counts, pending requests, connection creation and closure, body-consumption duration, and request outcomes. A pool that appears full might be serving legitimate long responses, leaking ownership after errors, or merely configured below a workload's necessary concurrency. These explanations call for different fixes.

The queue lab illustrates pending-work pressure rather than managing connections. For each independent run select Reset, explicitly set BOTH rates, predict, then Play or Step: compare λ=4, μ=3 with λ=2, μ=3. Both begin with backlog four at t=0; the first grows and the second reaches zero at four seconds. A rate edit retains elapsed time and recomputes from four, so do not treat edits as live pool-rate transitions. The fluid queue has no connection ownership, finite acquisition bound, or HTTP lifecycle; use pool instrumentation to test the real mechanism.