Don't put getaddrinfo on your proxy's hot path

Description and use

Optimizing DNS resolution in the Rust proxy Pingora boosts throughput from 21k to 89k req/s, narrowing the gap to nginx to 1.49× in a 2‑CPU container.

Problem

A Rust reverse proxy (Pingora) was six times slower than nginx in a CPU‑limited container due to blocking DNS lookups on every request.

Outcome

By moving DNS resolution out of the hot path and aligning thread count with CPU quota, Pingora’s performance improved from 21k to 89k req/s, narrowing the gap to nginx to 1.49x in a 2‑vCPU pod.

Workflow

• 1. Benchmark Pingora and nginx in identical containerized pod.
• 2. Observe Pingora’s low throughput and high latency.
• 3. Identify that HttpPeer::new builds the destination on every request, invoking getaddrinfo synchronously.
• 4. Resolve the backend address once at startup using to_socket_addrs().next().unwrap().
• 5. Store the SocketAddr and reuse it in HttpPeer::new for each request.
• 6. Re‑benchmark Pingora; observe throughput rise to ~89k req/s.
• 7. Document container setup, concurrency matrix, perf/strace profiles, flamegraph, and thread‑throttling data.

Evidence

Pingora went from 21k to 89k req/s in the same pod. The 6x was a getaddrinfo per request, not the framework.

Source

The real gap in a 2 vCPU pod is 1.49x — and perf pins it down to the cycle: Pingora runs 1.7x more instructions per request.

Source