--- title: "How we fine tune our RPC for speed and reliability" description: "We moved compression for large RPC responses to a better layer in our serving path, cutting P95 latency on heavy calls and reducing connection churn." --- # How we fine tune our RPC for speed and reliability We obsess about [performance](https://www.alchemy.com/benchmarks) and are constantly fine tuning to further optimize our platform. We recently changed how our platform compresses large RPC responses, and one part of that change had an outsized effect for Worldchain. Compressed responses on large calls now return about 33% faster, which means faster full block reads and other heavy calls, steadier performance, and more headroom to accommodate traffic growth. ## What is a GOAWAY frame? If you run a high-throughput workload over HTTP/2, you know GOAWAY frames even if you have never looked one up. A GOAWAY is the signal a server sends to tell a client to stop opening new streams on a connection, usually because the server is shedding load. To the client, a burst of GOAWAYs shows up as connection churn: streams get cut, requests get retried on fresh connections, and tail latency climbs. Fewer GOAWAYs means [steadier connections](https://www.alchemy.com/blog/how-alchemys-node-infrastructure-keeps-defi-fast-at-scale), fewer retries, and faster service. So when a customer's GOAWAY count falls off a cliff, something upstream just got a lot more headroom. In this case, that something was CPU. ## Where compression used to run Every RPC response we return can be compressed before it leaves our network. Most HTTP clients ask for this by sending an `Accept-Encoding: gzip` header, and most web servers, including our own [node-gateway](https://www.alchemy.com/blog/migrate-self-hosted-nodes-dedicated-infrastructure), honor that header automatically. That's not a special feature we built. It's standard behavior. For large payloads, like full block reads or big [`eth_getLogs`](https://www.alchemy.com/overviews/rpc-node) result sets, compression meaningfully cuts the number of bytes sent over the network, which matters because internet bandwidth is limited. Compressing in the node-gateway made sense for a long time. Node-gateway is an IO-bound service: it spends most of its time waiting on network calls, either from customers or from our own nodes, so it historically had CPU to spare. Compression is [CPU-bound work](https://www.alchemy.com/overviews/how-dedicated-blockchain-infrastructure-works), and its cost grows with response size. At scale, it became one of the busiest, most latency-sensitive jobs the gateway did, competing for the same CPU it needs to route and serve every request. When the gateway runs hot, everything it does slows down at once. And CPU pressure on the gateway under load is exactly the condition that triggers connection shedding and GOAWAY frames. ## What did we change? We moved where data compression happens out of our node-gateway and onto an Istio proxy in our service mesh. The node-gateway no longer compresses responses. That work now happens during a different step on an Istio proxy, on infrastructure better suited to it. So Alchemy's node-gateway is free to optimize for speed and reliability and Istio handles the compression step. The result is the same compressed response for our customers, produced somewhere that can do it more efficiently, without competing for cycles on the hop that gates performance. Same stack, same output, just done in a better place. ## What does this mean for you? Compressed responses on large calls now return about 33% faster (P95 latency improved by about 35%). That breaks down into three things. **Steadier connections.** When the hop serving your requests is not fighting for CPU, it stops shedding load, so you get fewer GOAWAYs, fewer cut streams, and fewer forced retries. That's what Worldchain saw: connection errors falling from roughly 1,500 an hour to roughly 100. **Faster responses on your heavy calls.** Handling compression on the Istio proxy lets the first byte of a big response leave sooner. For large payloads like full block reads or big `eth_getLogs` result sets, that means less time before the first chunk of a response arrives. **More headroom underneath you.** We freed up meaningful CPU capacity on the exact hop that gates your performance. The fix holds on a per-request basis, so it keeps holding as your traffic grows. You don't have to change anything to benefit. It's already running under every request you send. ## Why it matters Most of what makes an RPC provider fast and reliable happens where you never see it, in hops like this one. A single service doing less of the wrong work, in the right place, turned into steadier connections and faster responses overnight, with nothing for customers to change on their end. This is one change in an ongoing effort to improve our serving path. [Start building on Alchemy](https://www.alchemy.com/contact-sales).