{
  "id": 6648007,
  "title": "Don't put getaddrinfo on your proxy's hot path",
  "url": "https://urgent.news/2026/09/10/dont-put-getaddrinfo-on-your-proxys-hot-path",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-10T21:11:48.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/efraingaray/dont-put-getaddrinfo-on-your-proxys-hot-path-i31"
  },
  "original_language": "en",
  "account": "I conducted a benchmark test comparing Pingora 0.9.0, a Rust proxy library used by Cloudflare at its edge, to nginx in a specific environment: a small pod with limited CPU resources and two virtual CPU cores. Using the Pingora library alone, I achieved a request rate of 21,000 requests per second, while nginx achieved 126,000 requests per second under the same conditions. This result was incorrect, as Cloudflare would not use a proxy six times slower than nginx. To diagnose the issue, I isolated various factors such as CPU throttling, thread oversubscription, and connection reuse. Upon examining the latency, I discovered that the discrepancy lay in how the backend name was constructed. In the Pingora library, the backend was built on each request using the to_socket_addrs() function, which performed a blocking DNS query on the tokio worker thread. This synchronous call introduced a significant performance penalty in a containerized environment, where each request triggered a DNS query to Docker's resolver. In contrast, on the host, using an IP literal bypassed the syscall, resulting in minimal impact on performance. To address this issue, I implemented a simple fix: resolve the upstream addresses once at startup, store the resulting SocketAddr, and pass that address to the HttpPeer in the hot path of the proxy. After making this change, Pingora's request rate increased from 21,000 to 89,000 requests per second in the same pod, revealing that the initial comparison was misleading. The lesson learned is not specific to Pingora; it highlights the importance of avoiding blocking operations, such as DNS resolution, on the hot path of a proxy server. By resolving upstream addresses once and reusing the SocketAddr, the performance gap between the two proxies in a 2 vCPU pod narrowed to 1.49x. This improvement was primarily due to the increased instruction count per request in Pingora, which suggests that optimizing the proxy's performance involves minimizing unnecessary computations. I documented the entire process, including the container setup, concurrency matrix, performance profiling, and flamegraph, along with live diagrams and a reel, which can be found at the provided link. For anyone benchmarking a Rust proxy in a containerized environment, the key takeaway is to resolve upstreams by IP address or resolve them only once, and to set the thread count equal to the CPU quota allocated to the pod. These two adjustments can significantly impact the proxy's performance, making them more important than the choice of framework.",
  "summary": "I set out to benchmark Pingora 0.9.0 — the Rust proxy library Cloudflare runs at its edge — against nginx, in the environment I actually care about: a small pod with a CPU limit, two vCPUs, everything in containers so no number leans on the host. I wrote the simplest possible reverse proxy with Pingora, hit it, and got 21k requests/sec against nginx's 126k in the same setup . Six times slower.…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}