Load Testing Tor Hidden Services: Tools and Methodology

Tools like Apache Bench (ab), wrk, and siege perform well for clearnet HTTP testing because they make direct TCP connections. Applied to hidden services, they fail because: (1) they do not support SOCKS5 proxy, (2) Tor circuit latency (200-500ms) makes their default timeout assumptions wrong, (3) they do not account for circuit setup time as a separate phase from request latency, (4) the connection pooling models they use do not match Tor's circuit reuse behavior. Tor-aware load testing requires SOCKS5 proxy support and latency expectations calibrated to Tor's inherent overhead.

Before automated load testing, establish a manual baseline with curl through Tor SOCKS5. Use curl --socks5-hostname 127.0.0.1:9050 -w '@curl_timing_format.txt' -o /dev/null -s 'http://your.onion/page'. A custom write-out format captures: time_namelookup, time_connect, time_appconnect, time_pretransfer, time_redirect, time_starttransfer, time_total. This breakdown distinguishes circuit setup time (initial connection) from per-request latency. Run this 20-30 times to establish a latency distribution. Typical values: time_connect 100-500ms (circuit establishment), time_starttransfer 200-600ms (circuit + server TTFB), time_total depends on page size.

Locust supports SOCKS5 proxy through httpx with SOCKS proxy support. Configure Locust users to use httpx as the HTTP client with socks5://127.0.0.1:9050 proxy. Because each Tor instance has limited concurrent circuits, a realistic load test requires multiple Tor instances (each with a separate SocksPort) spread across multiple test machines. A Locust master coordinates distributed workers, each with their own Tor process. This setup approximates real user load where each user has their own Tor instance and circuit to the hidden service. Monitor Tor circuit count, bandwidth, and CPU on the server under test simultaneously with Locust metrics.

Tor latency follows a different distribution than clearnet HTTP. Clearnet latency is roughly normal-distributed around the network RTT. Tor latency has heavy tails - occasional circuit setup failures cause 30-60 second timeouts before retry. Load test results must be interpreted with this distribution in mind: median latency may be acceptable (500ms) while 99th percentile is terrible (15s) due to occasional circuit failures. Separate circuit setup failures from per-request latency in analysis. For hidden services targeting user experience quality, the 95th percentile latency is more actionable than average latency for identifying issues.

Use load testing data to extrapolate hidden service capacity. Identify the request rate at which latency begins to increase exponentially (the knee of the latency-throughput curve). This rate, minus a safety margin (typically 20-30%), is the sustainable throughput capacity. For a hidden service with horizontal scaling via OnionBalance, load test individual backend nodes to determine per-node capacity, then plan the number of nodes for target traffic levels. Document the load test methodology, Tor version, and infrastructure configuration so capacity planning can be re-validated after software updates or infrastructure changes.