Proxy RPS, Concurrency, Rotation and Cost: How to Measure a Pilot
Size a bounded proxy pilot using observed latency, valid results and billed traffic. Understand connection rotation and calculate cost per useful result with clearly hypothetical examples.
By PROXIES.SX Team. Published . 8 min read.
A throughput requirement needs a target, a payload and a time window. A client that launches requests quickly can still accumulate unfinished work, hit a connection limit and deliver few useful results. Measure the work completed and the traffic billed before choosing a larger budget.
First check country, network type and target fit. The arithmetic below uses invented workloads and prices to explain measurement. These examples are not a tested capacity claim, a quote or a guarantee for a particular country or target.
Separate request rate from work in progress
| Metric | What it answers |
|---|---|
| Started requests per second | How much work is the client introducing? |
| Completed requests per second | How quickly does work finish, including failures? |
| Valid results per second | How much usable output does the application receive? |
| Concurrent requests | How many requests are still in progress? |
| Open connections or tunnels | How many network connections remain open, including idle ones? |
With a stable workload, average requests in progress are approximately the completion rate multiplied by average request duration. For a hypothetical 20 completed requests per second and a two-second average duration, that is about 40 requests in progress. This assumes the queue is not continually growing and all measurements cover the same request boundary.
Connection reuse, multiplexing and idle tunnels can make the open connection count different. A configured timeout is a cancellation boundary, not the measured average latency. Keep separate records of average, p50, p95 and timeout counts, and confirm which unit the account limit measures.
Make rotation match connection behavior
The Pool Gateway rotation reference defines ondemand as choosing an endpoint for each new connection. With HTTP CONNECT, multiple requests inside the same tunnel can continue through the same exit. Choosing an endpoint again can also return the same public IP, particularly where several devices share carrier NAT.
For a test that requires a new selection each time, select on-demand rotation without a pinned session in the dashboard builder and use fresh connections for the measured attempts. Keep the chosen country and pool unchanged. Record connection reuse in your client so an unexpected repeated IP is not mistaken for a failed rotation request. If you need session continuity, test sticky behavior separately instead of mixing both modes in one result set.
Run a bounded pilot in stages
- Define valid output, countries, allowed target paths, expected payload and the test hours.
- Choose a small worker count, a traffic budget and a maximum run duration.
- Measure a baseline with retries disabled or separately labeled.
- Raise one setting at a time while staying within the account's confirmed limits.
- Stop when valid throughput stops improving, errors increase, the queue grows or the budget is reached.
Keep a bounded queue as well as a worker limit. Cancel timed-out work and close connections the application no longer needs. Use bounded retries with backoff and jitter for retryable failures, honoring a server's retry guidance where present. Count each retry as another attempt when calculating bandwidth and cost. Immediately retrying every failure can exhaust a limit faster.
Save results per country and target, then compare time windows. A successful pilot in one pool or quiet hour does not reserve the same capacity later. Before increasing a sustained workload, send support your pilot measurements and ask for confirmation of suitable supply and account limits.
Classify failures before adjusting limits
| Observed result | Next check |
|---|---|
| Proxy authentication failure | Generated username, proxy password and chosen protocol. |
| Gateway rejection or 429 | Error body, request ID, limit type and current open connections. |
| Connection timeout or reset | Connection stage, country, time window and whether any bytes arrived. |
| Target 403, 429 or challenge page | Target behavior and application fit, separately from gateway limits. |
| HTTP 200 with missing required data | Content validation; classify it as unusable output for this job. |
A status code alone may not identify who returned it. Preserve the sanitized error body and connection stage. Raising concurrency will not correct a wrong password or make an unsuitable target response useful.
Calculate cost per valid result from the billed window
Application response size and account traffic measure different things. Include requests, responses, retries and other proxy activity when reconciling a pilot. Browser subrequests and bytes transferred before an application failure can matter. Use the account's usage records for billed traffic and keep the client's byte totals as a separate diagnostic measure.
Hypothetical pilot calculation
Suppose 1,000 attempts produce 800 valid results and the isolated billing window records 2 GB. At an invented effective rate of $5 per GB, traffic costs $10. The valid-result rate is 80%, and the traffic cost per valid result is $10 / 800 = $0.0125.
Use your actual paid rate, metered units and billable traffic. Add any fixed fees and application costs separately. If other jobs share the account, an account-wide balance change cannot be assigned entirely to this pilot.
Estimate a larger run from valid results required and measured cost per result, then test the assumptions again at the next volume step. Keep unused prepaid balance separate from consumed traffic cost. A low nominal price per GB can still be expensive if most attempts return unusable output.
Send a capacity request with evidence
Include the target hostname, country and network type, request rate, concurrency, average and p95 latency, request/response sizes, valid-result rate, retry count and expected hours per day. Describe whether every new request needs a new connection or whether session continuity matters. Remove credentials and customer data from the examples.
Review current pricing alongside your measured pilot, and use the contact page for a capacity discussion before committing a larger workload. For scripts or agents, start with the documented account and gateway interfaces.