我们如何微调 RPC 以提升速度和可靠性

我们非常重视性能，并持续进行微调以进一步优化我们的平台。我们最近改变了平台压缩大型 RPC 响应的方式，其中一部分改动对 Worldchain 产生了超出预期的影响。大型调用的压缩响应现在返回速度提升了约 33%，这意味着更快的全区块读取和其他重负载调用、更稳定的性能，以及更充裕的空间来应对流量增长。

什么是 GOAWAY 帧？

如果你在 HTTP/2 上运行高吞吐量的工作负载，即使从未查过资料，你也一定见过 GOAWAY 帧。GOAWAY 是服务器发给客户端、告知其停止在某个连接上打开新流的信号，通常是因为服务器正在卸载负载。对客户端来说，一波 GOAWAY 表现为连接抖动：流被中断，请求在新连接上重试，尾部延迟随之上升。

更少的 GOAWAY 意味着更稳定的连接、更少的重试和更快的服务。所以当某个客户的 GOAWAY 数量骤降时，说明上游某处的空间突然变得充裕了。在这个案例中，那个"某处"就是 CPU。

压缩原来在哪里进行

我们返回的每个 RPC 响应在离开我们的网络之前都可以被压缩。大多数 HTTP 客户端通过发送 Accept-Encoding: gzip 头来请求压缩，而大多数 Web 服务器，包括我们自己的 node-gateway，都会自动遵循这个头。这不是我们专门构建的特殊功能，而是标准行为。对于大型负载，比如全区块读取或大型 eth_getLogs 结果集，压缩能显著减少通过网络发送的字节数，这一点很重要，因为互联网带宽是有限的。

长期以来，在 node-gateway 中进行压缩是合理的。Node-gateway 是一个 IO 密集型服务：它的大部分时间都花在等待网络调用上，无论是来自客户还是我们自己的节点，因此它历来都有富余的 CPU。压缩是CPU 密集型工作，其开销随响应体积增长。在规模化之后，它成了网关中最繁忙、对延迟最敏感的任务之一，与网关路由和处理每个请求所需的 CPU 争抢资源。

当网关负载过高时，它所做的一切都会同时变慢。而负载下网关的 CPU 压力，正是触发连接卸载和 GOAWAY 帧的条件。

我们改动了什么？

我们把数据压缩的执行位置从 node-gateway 迁移到了服务网格中的 Istio 代理上。node-gateway 不再压缩响应。这项工作现在发生在另一个步骤中，由更适合它的基础设施——Istio 代理来完成。这样 Alchemy 的 node-gateway 可以专注优化速度和可靠性，而压缩步骤则由 Istio 来处理。

最终结果是：客户得到的仍是相同的压缩响应，只是在能更高效完成这项工作的地方生成，不再与决定性能的那一跳争抢资源。技术栈不变，输出不变，只是执行位置更合理了。

这对你意味着什么？

大型调用的压缩响应现在返回速度提升了约 33%（P95 延迟改善了约 35%）。具体可以拆解为三点。

更稳定的连接。 当处理你请求的那一跳不再为 CPU 而争抢时，它就不会再卸载负载，因此你会看到更少的 GOAWAY、更少的流中断、更少的被迫重试。这正是 Worldchain 观察到的情况：连接错误从每小时约 1,500 次降到约 100 次。

重负载调用响应更快。 在 Istio 代理上处理压缩，让大型响应的首字节能更早发出。对于全区块读取或大型 eth_getLogs 结果集这类大负载，这意味着响应首个数据块到达前的等待时间更短。

底层空间更充裕。 我们在决定你性能的那一跳上释放出了可观的 CPU 容量。这项改进是按请求生效的，因此会随着你流量的增长持续保持效果。你不需要做任何改动就能受益——它已经在你发送的每个请求下运行了。

为什么这很重要

一个 RPC 提供商的快速与可靠，大部分体现在你看不见的地方，就像这一跳。一项服务减少了错误的工作、放在了正确的位置，一夜之间就带来了更稳定的连接和更快的响应，而客户那端完全不需要做任何改动。

这只是我们持续改进服务路径工作中的一项改动。开始在 Alchemy 上构建。