Skip to content

Performance and Connection Optimization

For scraping, HTTP/HTTPS automation, data collection, and other request-heavy workloads, connection reuse can materially affect observed latency. Performance also depends on the residential Node, destination, network conditions, and application behavior. Measure a representative workload before choosing timeouts, concurrency, or connection-pool settings.

Observed benchmark results

In a recent MyOwnProxy benchmark using one residential Node in one test environment, the following results were observed:

Measurement Observed result
Warm steady-state full-body latency Approximately 167 ms
Warm incremental overhead versus DIRECT Approximately 149 ms
Fresh-connection median full request latency Approximately 675 ms
Fresh-connection p95 full request latency Approximately 1.0–1.1 s

Full-body latency is the absolute measured request latency through completion of the response body. Incremental overhead is the difference versus a paired, contemporaneous DIRECT request made without MyOwnProxy under the benchmark conditions. The 167 ms and 149 ms figures describe different metrics and must not be added together.

The median is the middle observation. The p95 is the 95th percentile and describes the high-latency tail in the tested sample; it is not the typical or median result.

These are experimental observations from one Node and one environment, not a service-level guarantee or SLA. They do not predict latency for every Node or workload, isolate DNS timing, or establish throughput or capacity.

Fresh versus reused connections

A fresh connection (cold) requires creating a new connection path instead of reusing an established client connection. Depending on the proxy method, destination, and client behavior, setup can include:

  • A TCP connection to the proxy.
  • Proxy negotiation and authentication.
  • HTTP CONNECT setup for an HTTPS destination when using an HTTP proxy.
  • A TCP connection to the destination.
  • TLS establishment for HTTPS.
  • DNS resolution when required.

Not every phase occurs for every protocol or request.

A reused connection (warm) carries requests over an already established, reusable client connection where the client stack and destination allow it. Reuse can avoid repeated setup work and materially reduce per-request latency. An established connection can eventually close; reuse is possible only while the connection remains open and usable.

For Pool access, an established connection remains attached to the Node it used when opened. New connections use the Pool's Current Node; reusing a connection does not move it when selection is reevaluated. See Pool connection behavior.

Use fresh connections when verifying connection details, credentials, or Pool selection. Those checks serve a different purpose from measuring performance with realistic reuse.

SOCKS5 and HTTP CONNECT

SOCKS5 and HTTP CONNECT showed comparable warm steady-state latency in the tested conditions. This observation does not establish universal protocol equivalence or show that either method is inherently faster.

Choose primarily according to application/client compatibility and integration requirements, then benchmark the intended method with your workload. Protocol choice can still affect performance in other conditions.

For SOCKS5, HTTP proxy, and HTTPS through HTTP CONNECT configuration, use Connection Details, including its displayed endpoint rules and examples. Use the displayed hostname and matching protocol-specific port for the intended Pool or Direct Node access.

Client configuration recommendations

  1. Reuse client instances and sessions. Use your HTTP library or framework's persistent client, session, and connection-pooling facilities. Creating a client, sending one request, destroying it, and repeating for every request tends to reproduce fresh-connection setup costs.
  2. Allow supported connection reuse. For repeated requests to the same destination, or a compatible destination set where the client and servers permit it, use keep-alive and reusable connections. Depending on the method, this can avoid repeated proxy connection, negotiation/authentication, CONNECT, destination connection, and TLS setup. Finish reading response bodies and release response resources as required by your client library.
  3. Size pools for the workload. Configure a connection pool appropriate for application concurrency and target-server limits. Too little reuse repeats setup work; excessive idle connections consume resources and can become stale. Benchmark pool size and idle timeouts with the actual workload rather than adopting a universal size. Prefer persistent connections when latency matters and the workload permits them, while respecting destination policies and connection limits.
  4. Handle stale connections. Target-server or intermediary idle timeouts, network changes, and normal connection lifecycle can close reused connections. Allow the client to discard an unusable connection and establish a fresh one. Retry a request only when it is safe to repeat; an uncertain response does not prove the destination did not process it. Use bounded retries and timeouts appropriate to the operation.
  5. Measure realistic requests. Benchmark the actual target service with representative residential Node geography, concurrency, payload sizes, the intended protocol, and realistic connection reuse. Measure fresh and reused connections separately, including median and tail latency, before selecting operational settings.

What affects latency

  • Residential Node and destination geography.
  • The residential ISP, current Internet routing, and network conditions.
  • DNS timing when a lookup is required.
  • TCP/TLS setup and the application's connection-reuse pattern.
  • Target-server response time and payload size.
  • Application concurrency and connection-pool behavior.

The benchmark figures summarize request latency rather than any individual setup phase. See Residential DNS resolution for the documented DNS behavior.