Why Can't You Just Look at Average Latency Even When the Same Script Runs?
Average latency only speaks to overall speed — it can't represent proxy quality on its own. The same script, target address, and request parameters do reduce variable interference, but final results are still affected by test window, target site response, network egress, concurrency, and connection-reuse pattern.
This test needs to lock down at least these conditions:
| Test Item | Unified Measure |
|---|---|
| Request script | Same version, same request logic, same timeout setting |
| Request target | Same batch of public pages or endpoints |
| Request method | GET, POST, or other method held consistent |
| Concurrency config | Fixed concurrency; don't adjust mid-test |
| Test cycle | Continuous runtime for one week |
| Statistical unit | Per request, per proxy channel, or per time window |
| Exception handling | Log timeouts, connection failures, and status-code anomalies separately |
If you change target, concurrency, or timeout mid-test, results stop being a strict head-to-head comparison and only serve as stage-level observation.
Which Latency Number Should You Look At?
Look at average latency, P50 latency, and P95 latency together. Averages can be pulled up by a few extreme slow requests and can also mask the real experience of most requests.
| Metric | What It Represents | What It's Good For Judging |
|---|---|---|
| Average latency | Average time across all requests | Overall speed level |
| P50 latency | Half the requests fall below this value | Typical experience of routine requests |
| P95 latency | 95% of requests fall below this value | Long-tail requests and stability |
| Max latency | Slowest request's time | Whether extreme jitter exists |
| Timeout rate | Share of requests that didn't complete within the set time | Whether long tasks are prone to interruption |
If a plan has lower average latency but noticeably higher P95 latency, it may have long-tail variance. For one-off requests, this difference may not stand out; for continuous data-monitoring tasks, long-tail latency accumulates into task queuing, processing timeouts, and more retries.
So the result table shouldn't just say "lowest average latency." A more accurate statement:
- Average latency sits at [TBD]
- P50 latency sits at [TBD]
- P95 latency sits at [TBD]
- Max latency is [TBD]
- High-latency requests cluster mainly in [TBD time window]
How Should Success Rate Be Calculated?
Success rate must define what "success" means before statistics begin. If only HTTP 200 counts as success, you can miss cases of empty business content, missing response fields, or incomplete page loads.
Split into at least three layers:
- Connection success rate: whether the proxy connection completed and the target response was received.
- Request success rate: whether the expected status code returned within the set time.
- Business success rate: whether returned content meets the script's validation conditions.
For example, the target page returns a normal status code but a key field is empty. This request counts as a success at the connection layer, but still as a failure at the business layer. Mixing the three measures together makes results across plans incomparable.
| Statistical Measure | Result |
|---|---|
| Total request count | [TBD] |
| Connection success count | [TBD] |
| Request success count | [TBD] |
| Business validation success count | [TBD] |
| Connection failure count | [TBD] |
| Timeout count | [TBD] |
| Status-code anomaly count | [TBD] |
| Content validation failure count | [TBD] |
Recommended formulas:
Request success rate = Requests returning expected status within the set time ÷ Total requests × 100%
Business success rate = Requests passing content validation ÷ Total requests × 100%
Timeout rate = Requests exceeding the timeout ÷ Total requests × 100%If the article ultimately answers "is the success rate high," prioritize business success rate and specify the measurement basis.
In a Week of Testing, Which Time Windows Most Likely Open the Gap?
Peak and off-peak must be counted separately — don't let full-day averages substitute for the full conclusion. Tunnel proxies may behave differently across time windows, especially under sustained requests and concurrent tasks.
Split the week's data by these dimensions:
| Dimension | Suggested Grouping |
|---|---|
| Time window | Morning, working hours, evening, overnight |
| Workday | Mon-Fri, weekend |
| Concurrency | Low, medium, high |
| Request type | Page request, API request, content-validation request |
| Error type | Timeout, connection failure, status anomaly, content anomaly |
| Single task | First connection, continuous requests, retry requests |
If a plan performs normally at low concurrency but success rate drops fast under high concurrency, it fits lightweight tasks better and shouldn't be extrapolated directly to continuous production business. Conversely, if average latency is slightly higher but all-day variance is small, it may fit tasks with higher continuity requirements better.
The by-window results for this test should be filled in as:
| Time Window | Avg Latency | P95 Latency | Success Rate | Timeout Rate | Main Anomalies |
|---|---|---|---|---|---|
| Morning | [TBD] | [TBD] | [TBD] | [TBD] | [TBD] |
| Working hours | [TBD] | [TBD] | [TBD] | [TBD] | [TBD] |
| Evening | [TBD] | [TBD] | [TBD] | [TBD] | [TBD] |
| Overnight | [TBD] | [TBD] | [TBD] | [TBD] | [TBD] |
What If Latency Is Low but Success Rate Isn't High?
When latency and success rate diverge, check failure request types first — don't rush to judge whether the plan is good or bad. Low latency may mean fast connection establishment, but it doesn't guarantee the target response is complete; high success rate may stem from small request volume or simple test targets.
The four common result combinations:
| Latency | Success Rate | Possible Explanation |
|---|---|---|
| Low | High | Speed and continuity both good; still confirm peak-hour stability |
| Low | Low | Fast connection, but likely timeouts, status anomalies, or content validation failures |
| High | High | Request completion is good, but task time and concurrency cost may be high |
| High | Low | Neither speed nor completion is ideal; investigate connection, target, and script configuration |
If failures mainly come from connection timeouts, focus on node switching, connection reuse, and timeout settings. If failures mainly come from business content validation, investigate target response, request parameters, and script judgment conditions. A single "success rate" column can't distinguish these causes.
What Else Can Affect Results When the Same Script Runs for a Week?
A unified test script doesn't mean a fully consistent test environment — raw logs still need to be retained. During a week of testing, target page content, network state, request frequency, and proxy channel state can all change.
Retain at least these raw fields:
- Request time
- Request ID
- Proxy channel identifier
- Target address
- Connection time
- Time to first byte
- Full response time
- HTTP status code
- Response body size
- Error type
- Whether retried
- Retry count
- Business validation result
"Whether retried" is especially important. If one plan has more retries but still a higher final success rate, it can't be compared on the same measure as a plan without retries. The article should list first-request success rate and final-task completion rate separately — don't hide the improvement that retries bring.
How Should the Final Result Be Written to Avoid Turning One Test into a Universal Conclusion?
A week of testing only speaks to performance under current test conditions — it can't derive fixed conclusions across all scenarios. Result descriptions should state test scope, time window, request scale, and limiting conditions together.
Recommended conclusion structure:
- Between [test time] and [test time], the same script completed [TBD] requests.
- Under the test target and concurrency configuration, Plan [TBD] shows average latency of [TBD] and P95 latency of [TBD].
- Plan [TBD] shows business success rate of [TBD], with main failure type [TBD].
- In evening or high-concurrency windows, results showed [TBD] variation.
- This conclusion only applies to the current target, network environment, concurrency configuration, and measurement basis — re-validate when target or configuration changes.
So the article shouldn't directly write "Provider X has lowest latency and highest success rate" unless raw data, measurement basis, and test conditions are all fully disclosed. A safer phrasing:
Under this one-week test's fixed target, concurrency, and timeout settings, Plan [TBD] shows [TBD] on the latency dimension; Plan [TBD] shows [TBD] on the business success rate dimension. The two results don't fully align — real selection should depend on whether the task weights response speed, continuous completion rate, or peak-hour variance more heavily.
FAQ
Q: Is it OK to only look at average latency when testing tunnel proxies?
Not recommended. Average latency only reflects overall time cost — it can't speak to long-tail requests and peak-hour variance. At minimum, look at P50, P95, max latency, and timeout rate together to tell the difference between routine experience and extreme cases.
Q: What success rate counts as suitable for long-term tasks?
No universal number without scenario. Long-term tasks care more about business success rate, continuous runtime duration, timeout distribution, and recovery methods after failure. Testing should also fix target, concurrency, and timeout settings — otherwise results aren't directly comparable.
Q: Why can business results still fail when connections succeed?
A successful connection only means the proxy chain was established and a response received — it doesn't mean the response content meets task requirements. Empty target pages, missing key fields, status anomalies, or failed content validation can all cause business failures.
Q: Is a week of testing enough to make a selection decision?
A week of testing can surface initial differences but can't substitute for long-term validation. Before formal use, add testing across different time windows, concurrency levels, and target types, and retain raw logs to confirm results are repeatable.
Q: Can latency and success rate only pick one metric?
No need to choose. Tasks with high real-time requirements can weight latency metrics higher; continuous monitoring and batch processing should weight business success rate, timeout rate, and peak-hour stability higher. Weights should be set by task goals.
Q: Can you publish test conclusions without complete raw logs?
You can publish test method and stage-level observations, but not precise rankings or absolute conclusions. When total request count, failure types, retry counts, or by-window data are missing, label the data as insufficient and limit the conclusion to the current observation scope.
