Proxy concurrency: size your parallel connections

Short answers

Give each count its own name

A plan saying “many threads” does not tell you how your application will behave. First identify what your software counts. A browser worker, a Python task and a TCP connection do not necessarily correspond one to one. Reusing an HTTP connection and opening several browser subrequests can produce different relationships.

A semaphore limits work occupying its slots; it does not by itself establish a requests-per-second limit. A fast endpoint can cycle through those slots many times in a second. Python’s semaphore reference explains the slot counter. Apply a separate destination-rate policy and a finite queue instead of scheduling an unbounded list of tasks.

Measure a representative authorised task

1. Confirm the destination permits the task and record its rate, concurrency and access conditions.
2. Run one small representative task with retries disabled, a deadline and bounded response handling.
3. Record start/completion times, request count, useful results, errors and bytes; identify browser assets separately.
4. Check the client pool and current account connection/session limits before allowing parallel work.
5. Choose a low initial worker cap and a separate request-start ceiling, then repeat the same bounded sample.

Measure more than latency. A response that arrives quickly but contains an error is not a successful observation. Keep useful-result counts separate from attempts, and include retry traffic when estimating cost. The proxy trial evaluation guide owns the fuller test checklist; GB sizing owns the traffic budget.

Use a fictional rate-and-duration worksheet

Suppose an authorised endpoint permits at most four request starts per second and a representative request occupies an in-flight slot for an average 1.5 seconds. At a steady four starts per second, the average work in flight would be approximately 4 × 1.5 = 6 requests. This is planning arithmetic, not a performance result or permission to run six connections against another destination.

With two continuously busy single-request workers and that same duration, the rough average completion capacity is 2 ÷ 1.5, about 1.33 requests per second. It is lower than the four-start ceiling, which is acceptable. You do not need to exhaust an allowed rate. Variability, queueing, response bodies, destination errors and client connection reuse can change the observed result.

Longer requests occupy slots for longer. If the same workload slows to three seconds, the six-in-flight estimate no longer represents the earlier four-per-second rate. Re-measure rather than adding retries or workers automatically. Browser navigations need their own measurements because one page can start multiple resource requests; a navigation-worker cap is not a request-start ceiling.

Set client limits without confusing them with permission

HTTPX documents a connection-pool limit separately from keep-alive connection retention. Those controls do not create a destination rate policy. Its exception reference also distinguishes PoolTimeout: waiting too long for a pool slot is a client-side observation to inspect before increasing load.

import httpx

limits = httpx.Limits(
    max_connections=2,
    max_keepalive_connections=2,
)
timeout = httpx.Timeout(10.0, pool=2.0)

# Configuration only: no requests are sent by this example.
# A real worker also needs destination pacing, a bounded queue,
# a whole-task deadline, response limits and correct proxy settings.
with httpx.Client(limits=limits, timeout=timeout) as client:
    pass

Use HTTPX proxy setup for a complete bounded connection check. For a multi-step workflow, associate its permitted application state with the intended session. Read sticky sessions and rotation before allocating session names; rotation does not reset application state or promise a distinct address for every worker.

Respond to limits before adding work

Portproof’s shared traffic product has connection and session limits per account, shown in the dashboard. Multiple applications share those limits and the GB balance. There is no fee per connection, but traffic usage remains billable according to the product’s counting rules. Buying extra GB does not establish a higher concurrency allowance.

When a 429 or gateway limit error appears, pause new work for the affected scope and inspect the response and account state. RFC 6585 defines 429 rate limiting; a Retry-After value can state a wait. Honour the response guidance, reduce pressure and retry only operations safe to repeat, within a finite attempt budget. Missing retry guidance does not permit an immediate retry loop.

The 429 guide distinguishes gateway connection/session errors from a destination’s response and explains bounded retry decisions. Authentication, TLS and parser errors also need their own correction; more workers will not fix them. Keep an interrupted task incomplete until you know its result.

Size allowance and access separately

Once the small run is useful, estimate its traffic from measured attempts and bytes, then compare current proxy prices. Shared mobile and residential traffic uses one GB balance; it does not reserve a device or fixed IP per worker. If you need a separately rented mobile device, review dedicated mobile ports, their current terms and stock. Device access alone does not establish a throughput promise.

Sources and scope

Primary references checked 30 October 2026: HTTPX resource limits, HTTPX exceptions, Python semaphores and RFC 6585. Worksheet values are fictional and checked arithmetically. No live gateway capacity, destination load test or throughput benchmark is claimed.

What is not allowed

Run checks only where you have permission, respect destination limits and follow the acceptable-use policy.

Read next