RPC 延迟缓慢：原因、测量与修复

什么导致 RPC 延迟缓慢？

当您的区块链应用感觉缓慢时，第一个怀疑对象通常是 RPC 端点。但“RPC 延迟”并不是一个单一的数字；它是网络往返时间、节点处理时间和排队延迟的组合。理解每个组成部分是修复它的第一步。

您观察到的总延迟是以下各项的总和：网络延迟（数据包在您的客户端和节点之间传输的时间）、节点处理时间（节点执行请求所需的时间，取决于方法和节点负载）以及排队延迟（如果节点繁忙，您的请求将排队等待）。例如，一个简单的 eth_blockNumber 请求在本地节点上可能只需 10 毫秒，但在跨洋的公共端点上可能需要 200 毫秒。

主导因素通常是网络距离。光在光纤中每 1000 公里大约传播 5 毫秒，但由于路由和拥塞，实际延迟更高。从纽约到东京节点的请求往返时间很容易达到 150-200 毫秒。节点负载是第二个主要因素：如果节点正在处理许多重查询（如大范围的 eth_getLogs），您的请求可能会排在它们后面。

最后，查询本身也很重要。某些 RPC 方法本质上开销较大。例如，eth_getLogs 在区块范围较大时可能需要几秒钟，而 eth_blockNumber 几乎是即时的。如果您的应用频繁进行高开销调用，即使节点很快，您也会看到高延迟。

为了获得清晰的图像，您需要分别测量每个组件。本文的其余部分将向您展示如何操作。

• 网络延迟：客户端和节点之间的往返时间，受地理和路由影响。
• 节点处理时间：节点执行请求所需的时间，取决于方法和负载。
• 排队延迟：等待节点空闲的时间，在负载下增加。
• 查询成本：某些方法（例如 eth_getLogs）比其他方法慢得多。

如何可重复地测量 RPC 延迟

要测量 RPC 延迟，您可以使用带有 -w 选项的 curl 来捕获计时细节。这为您提供了一种无需特殊工具的可重复方法。以下命令向公共端点发送一个简单的 eth_blockNumber 请求，并打印总时间：

运行此命令几次以了解分布情况。time_total 是 HTTP 请求的总时间，包括网络和节点处理。要将网络延迟与节点处理分开，您可以使用 time_connect（TCP 握手）和 time_starttransfer（到第一个字节的时间）。

为了更稳健的测量，您应该收集多个样本并计算百分位数。p50（中位数）告诉您典型延迟，而 p99（第 99 百分位）揭示尾部延迟，这对用户体验至关重要。您可以使用一个简单的脚本发送 100 个请求并计算这些值。

以下是一个 bash 脚本，发送 100 个请求并使用 awk 和 sort 计算 p50、p95 和 p99。它假定您已安装 curl 和 jq。

curl -s -o /dev/null -w "time_total: %{time_total}s\n" -X POST https://eth.api.onfinality.io/public -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

解读数字：什么是“良好”的 RPC 延迟？

一旦您有了测量结果，您需要一个基准。对于公共 RPC 端点，p50 低于 100 毫秒通常是可以接受的，低于 50 毫秒则很好。然而，对于交易应用或实时交互，您可能需要 p99 低于 100 毫秒。作为参考，从美国东海岸客户端到美国西海岸节点的典型往返时间约为 70 毫秒；到欧洲约为 140 毫秒；到亚洲则为 200 毫秒或更多。

如果您的 p50 较高但 p99 高得多，您可能遇到节点负载问题。如果两者都高，则可能是网络距离。您可以通过比较本地节点（如果有）和远程公共端点来测试这一点。如果本地节点快得多，则网络是瓶颈。

此外，考虑您测量的方法。eth_blockNumber 是最便宜的方法；如果它很慢，其他一切都会更慢。为了更真实的测试，测量您的应用实际使用的方法，例如 eth_getBalance 或 eth_call。

请记住，延迟不等于吞吐量。节点可能具有低延迟但低吞吐量，反之亦然。对于高吞吐量应用，您可能需要批处理请求或使用 WebSocket 订阅来减少往返次数。

• p50 < 100 毫秒：对于大多数公共端点可接受。
• p50 < 50 毫秒：对于交互式应用良好。
• p99 < 100 毫秒：对于交易或实时应用必需。
• 比较 p50 与 p99 以识别负载与网络问题。

降低延迟：地理端点和提供商选择

降低网络延迟最有效的方法是使用地理上靠近您的应用的端点。如果您的用户在欧洲，请使用欧洲端点；如果他们在亚洲，请使用亚洲端点。许多提供商（包括 OnFinality）提供区域端点。例如，OnFinality 的 Polkadot RPC 端点 包括不同地区的选项。

选择提供商时，寻找具有全球边缘网络的提供商。OnFinality 的 RPC 服务 将请求路由到最近的节点，减少往返时间。同样，对于以太坊，您可以使用 最佳以太坊 RPC API 提供低延迟访问。

如果您正在 Hyperliquid 上构建交易机器人，延迟至关重要。查看我们的指南 用于低延迟交易的最佳 Hyperliquid RPC 提供商，了解哪些提供商提供最快的连接。

对于 Solana，网络专为高吞吐量设计，但延迟仍然重要。请参阅我们的 Solana RPC 端点 页面获取推荐提供商。

最后，如果您有资源，考虑运行自己的节点。本地节点完全消除网络延迟，但需要维护，并且如果节点性能不足，仍然可能很慢。对于许多应用，精心选择的公共端点就足够了。

降低延迟：批处理、订阅和缓存

即使网络很快，您也可以通过减少往返次数来降低感知延迟。JSON-RPC 批处理允许您在单个 HTTP 请求中发送多个请求，减少网络开销。例如，如果您需要获取 10 个余额，您可以发送一个批处理请求而不是 10 个单独的请求。这对于高延迟网络尤其有效。

在我们的文章 JSON-RPC 批处理最佳实践 中了解如何正确实现批处理。批处理可以将总时间从 N * 延迟减少到大约 延迟 + N * 处理时间，这是一个巨大的胜利。

另一种技术是使用 WebSocket 订阅而不是轮询。订阅在数据变化时推送数据，消除了重复请求的需要。这对于价格馈送或交易监控等实时应用非常理想。WebSocket 连接在初始握手后也具有较低的开销。

缓存也很强大。如果您重复获取相同的数据（例如区块号、Gas 价格），请在客户端缓存并以合理的间隔刷新。这减少了节点负载并提高了应用的响应能力。

最后，如果您有高流量，考虑使用专用节点。公共端点是共享的，因此您可能会遇到速率限制或排队。专用节点为您提供一致的性能。OnFinality 提供 专用节点 并附带 SLA。

诊断常见延迟问题

如果您已测量但延迟仍然很高，以下是常见问题需要检查：

1. DNS 解析： 解析端点主机名的时间可能增加 10-50 毫秒。使用 curl -w "time_namelookup: %{time_namelookup}s\n" 测量。如果很高，考虑直接使用 IP 地址或更快的 DNS 提供商。

2. TLS 握手： HTTPS 增加握手，可能需要 20-100 毫秒。使用 time_appconnect 测量。您无法避免 TLS，但可以使用 keep-alive 重用连接。

3. 节点过载： 如果节点返回错误或响应缓慢，则可能过载。检查节点的状态页面或使用健康检查端点。如果您使用公共端点，请尝试另一个进行比较。

4. 防火墙或代理： 公司网络或 VPN 可能增加延迟。从不同网络测试以隔离。

5. 客户端问题： 您的应用可能顺序发出请求，而它们本可以并行。使用异步调用或批处理。

有关系统方法，请阅读我们的指南 监控 RPC 端点，以设置延迟峰值警报。

权衡与限制

虽然您可以降低延迟，但存在权衡。地理端点可能具有不同的数据可用性或可能不太可靠。例如，对等节点较少的区域中的节点可能具有更高的同步延迟。此外，批处理可能增加节点负载，因此请谨慎使用。

订阅需要维护持久连接，这可能更复杂。缓存如果未正确失效可能导致数据过时。专用节点成本更高。

最后，请记住 RPC 延迟只是等式的一部分。您的应用性能还取决于区块链的共识时间、区块时间和代码效率。在责怪 RPC 之前，先优化您的代码。

有关相关问题的深入探讨，请参阅我们的文章 如何修复 RPC 超时错误 和 监控 RPC 端点。

下一步：构建延迟预算

既然您知道如何测量和降低延迟，请为您的应用创建延迟预算。决定您需要的 p50 和 p99，并定期测试您的端点。使用上述技术来满足您的预算。

如果您使用 OnFinality，您可以利用我们的 全球网络 获得对多个链的低延迟访问。查看我们的 定价 了解专用选项。并探索 how to choose an RPC provider 以找到最适合您需求的端点。

请记住，延迟是一个移动目标。随着您的用户群增长或应用变化，重新评估您的端点和架构。定期监控是关键。