Before a collection pipeline goes to production, someone reasonably asks whether it will hold up at full volume. The instinct is to run a load test, and the instinct is right, but proxy load testing has a constraint that ordinary load testing does not: the thing you are pushing traffic at usually belongs to someone else.
That single fact reshapes the exercise. You are not testing whether a system can absorb your load, you are characterising your own pipeline’s behaviour and finding your ceiling, without conducting an unannounced stress test against a third party. Here is how to do that properly.
What you are actually testing
Separate the four questions, because they need different tests and only one of them involves a real target.
Your own pipeline’s capacity. How many concurrent requests your workers, connection handling, parsing and storage can sustain before something saturates. This is a test of your code and infrastructure and can be run without touching anyone else’s site.
Proxy path behaviour under concurrency. How latency and success rate move as you increase in-flight requests through the gateway. Also mostly independent of any particular target.
The target’s tolerance. What pace a specific site accepts before it throttles or challenges you. This is the one that must be approached carefully and incrementally rather than with a load generator.
End-to-end throughput. What all of the above produce together, which is the number your schedule actually depends on.
Conflating them produces the classic bad outcome: a “load test” that hammers one target, gets blocked, and tells you nothing except that you can get blocked.
Test against something you own first
Stand up a target you control that returns a response of realistic size, and point the pipeline at it through the proxies. This isolates everything except the third party.
You learn a surprising amount here. Whether your worker pool actually reaches the concurrency you configured. Whether connection handling is doing what you think, since pooled connections behave differently through a gateway, per IP not rotating. Where your parsing or storage becomes the bottleneck. And what latency distribution the proxy path adds, without a target’s own variability mixed in.
Use realistic payload sizes. A test against a tiny endpoint will overstate your throughput badly, because bandwidth and parsing both scale with response size and residential latency dominates differently at different payload sizes.
Measure the right things
Throughput alone is a poor summary. Five measurements make a load test interpretable.
Validated success rate, not HTTP success. A test that reports 100% success while returning challenge pages is measuring the wrong thing, per detecting blocked or fake content.
Latency percentiles, specifically p50, p95 and p99. Residential latency has a wide distribution, so an average conceals the tail that actually determines whether a time-boxed job finishes.
Throughput as a function of concurrency, plotted rather than sampled at one point. The interesting feature is where the curve flattens, since beyond that you are adding in-flight requests without adding completions.
Error class distribution, because the mix tells you what is limiting you. Timeouts point one way, rate signals another, and challenges another again, per common residential proxy errors.
Bytes per request, since it determines cost at production volume and is easy to measure now and expensive to discover later, per estimating monthly bandwidth.
Ramp, do not spike
Increase concurrency in steps, hold each step long enough for the numbers to settle, and record the full set of measurements at each level. A spike test tells you almost nothing useful here, because the failure it produces is indistinguishable from a target reacting to a burst.
The shape you are looking for is where throughput stops rising with concurrency, and where p95 latency starts climbing sharply. Those two usually coincide and mark your practical ceiling. Run your production job somewhere below it rather than at it, because the ceiling moves with target behaviour, time of day, and pool conditions.
for concurrency in [5, 10, 20, 40, 80]: stats = run_step(concurrency, duration_seconds=180) # hold, then record print(concurrency, stats.validated_success, stats.p50, stats.p95, stats.rps, stats.bytes_per_req, stats.error_mix) if stats.validated_success < 0.9 or stats.p95 > LATENCY_BUDGET: break # found the kneeCalibrating against a real target, carefully
Eventually you need to know what your actual sources tolerate, and that cannot be learned from a mock. Do it as calibration rather than as a load test.
Start well below your intended rate and increase slowly, watching validated success rate rather than status codes. Stop increasing at the first sign of degradation rather than pushing to failure, since the objective is to find a sustainable pace, not a breaking point. Spread the calibration over a longer period than feels necessary, because throttling is often applied over rolling windows and a short burst can pass while a sustained rate does not.
Honour what the target tells you. A 429 or a Retry-After is a direct instruction and the right response is to slow down rather than to rotate addresses so you can maintain the pace, which is the distinction in rate limiting and throttling.
And keep it proportionate: your calibration traffic should be a rounding error against the site’s normal load. Deliberately stress-testing a third party’s infrastructure is not a benign engineering exercise, and depending on scale and intent it can cross into interference. If you need to know a partner’s limits precisely, ask them.
Reading the results
Translate the curve into the two numbers your production configuration needs: a per-target concurrency cap and a per-target rate, both set below the knee with headroom.
Then sanity-check against your schedule. Concurrency follows from rate and latency, so if your measured p50 latency is higher than you assumed, the concurrency you need for a given deadline rises accordingly, which is the arithmetic in planning request volume and concurrency.
Finally, treat the results as perishable. Target defences change, pool conditions vary by hour and market, and a number measured in a quiet week will not hold during a peak. Re-run calibration periodically and, more importantly, run the same measurements continuously in production so the ceiling is observed rather than assumed, per monitoring proxy health at scale.
The bottom line
Proxy load testing is capacity characterisation, not an assault on a third party. Separate the four questions and test the first two against infrastructure you own with realistic payload sizes, which isolates your pipeline’s real bottlenecks from a target’s variability. Measure validated success rate, latency percentiles, throughput against concurrency, error class mix and bytes per request, then ramp in steps and look for the knee where throughput flattens and p95 climbs. Calibrate against real targets slowly and stop at the first degradation rather than pushing to failure, honouring rate signals by slowing down rather than rotating. Set production caps below the knee, re-derive your concurrency from measured latency, and keep measuring in production because the ceiling moves.
The path being tested is residential proxies, where concurrency and geography are per-request parameters rather than plan settings, billed per GB so a well-scoped load test costs about what its bandwidth costs.