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

说明与用途

在 Rust 代理 Pingora 中优化 DNS 解析，将吞吐量从 21k 提升至 89k 请求/秒，缩小 2 CPU 容器中与 nginx 的差距至 1.49 倍。

问题

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

结果

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.

工作流

• 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.

证据

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

来源

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.

来源