Load Testing Tor Onion Services

Standard tools like Apache Bench (ab) and wrk cannot use SOCKS proxies directly. Use alternatives that support SOCKS5: wrk with proxychains (proxychains4 -q wrk -t4 -c100 -d30s http://yoursite.onion/) or Locust with a SOCKS5-aware HTTP library. The Python requests library with the requests[socks] package enables SOCKS5 connectivity by setting proxies to socks5h://127.0.0.1:9050. Write Locust tasks using this session configuration to simulate realistic user behavior across the Tor network. For circuit-aware testing, use stem (Python) to control the Tor daemon, pre-build circuits, and assign specific circuits to test connections.

During load testing, Tor creates new circuits as connection demand increases. A single Tor client instance managing 100 concurrent test connections uses multiple circuits. Circuit build latency (typically 1-3 seconds) inflates time-to-first-byte measurements during ramp-up but not during steady-state. Warm up the circuit pool before measuring: send 20% of target load for 60 seconds before capturing metrics. Monitor circuit count via the Tor control port with GETINFO circuit-status during the test.

Load testing often reveals database query bottlenecks that Tor circuit latency masks during normal traffic. When connection volume increases, slow queries that complete in 100ms under light load may take 2-5 seconds under concurrent access, combined with Tor's inherent latency making total response time unacceptable. Profile database queries during load tests using EXPLAIN ANALYZE in PostgreSQL or SHOW PROFILE in MySQL. Implement connection pooling with PgBouncer for PostgreSQL to avoid connection exhaustion. Cache frequently accessed query results in Redis with appropriate TTL.

OnionBalance distributes traffic across multiple backend instances by advertising a single onion address that maps to multiple introduction points across different servers. Load testing an OnionBalance setup requires understanding that circuit routing is probabilistic. Measure backend-specific throughput by instrumenting each backend with Prometheus metrics and comparing request rates during load tests. If one backend receives disproportionate traffic, it may indicate a rendezvous point concentration issue. Test individual backends directly by their own onion addresses to establish per-server capacity before measuring the aggregated OnionBalance endpoint.

Key metrics for onion service load testing differ from clearnet benchmarking. Time-to-first-byte (TTFB) is typically 200-800ms even for optimally performing onion services due to circuit overhead - do not confuse this with application slowness. Focus on 95th and 99th percentile response times, which reveal outliers caused by slow circuit building or backend contention. Connection success rate indicates circuit availability. Error rates should remain below 1% during steady-state load. Circuit recycling rate (circuits created per minute divided by concurrent connections) should be low and stable during steady-state.