如何针对你的工作流对 RPC 提供方做基准测试

选择 RPC 提供方，应当依据针对你自己工作负载的基准测试。我们一直在对各家提供方做基准测试，包括我们自己，也见过很多团队这样做。发送请求是容易的部分。难的是决定衡量什么，然后搭建一个你真正愿意据此做决定的测试。

所以我们把方法论写了下来，并构建了 Alchemy rpcbench 来执行它：一个单一的二进制文件，在你自己的机器上，针对你的应用实际调用的方法，对任意一组 RPC 提供方做基准测试。方法论本身也适用于你已有的任何工具。

值得衡量的有三件事：负载下的延迟、区块滞后和数据一致性。每一项会影响系统的不同部分，一家提供方可能在一项上很强、在另一项上落后，因此混合评分会掩盖你真正关心的那一项。衡量你的应用实际调用的内容，并在它运行的地方测。

对 RPC 提供方做基准测试时，应该衡量什么？

负载下的延迟、区块滞后和数据一致性，分别衡量、分别报告。

数据一致性是大多数团队从不测试的一项。有些提供方用不同的后端服务不同的方法，而这些后端并不总是同步推进，因此一家提供方可能已经公布了新区块头，而同一区块的日志返回时却不完整。可以想象一座图书馆，在书上架之前就更新了目录：目录说新书已到，书架上却是空的。

应该先衡量哪一项？

从与你的应用如何使用数据相匹配的那一项开始。如果你根据新区块采取行动，那就是区块滞后。如果你在区块落地的那一刻读取它的日志或状态，那就是数据一致性。否则就是负载下的延迟。我们见过 Valantis、Aave、RedStone 和 Struct 等团队，各自运行衡量不同内容的基准测试。

然后逐个方法比较提供方，因为平均更快的提供方，在你的应用调用最多的那一个方法上仍可能更慢。这个差距就是关键所在：价差消失后才到达的报价不是慢报价，而是错失的成交。

如何运行一个可信的 RPC 基准测试？

按固定的时间表发送请求来衡量延迟。显而易见的设计是发送一个请求、等待响应、再发送下一个，而这恰恰会在提供方开始吃力时悄悄减少请求。你的测试在本应保持稳定的时刻放缓了，于是你想找的那次变慢永远不会出现在数据里。改为按固定时钟发送，并记录每次发送相对时钟落后了多少。当你自己的机器跟不上时，数字描述的就是你的机器。

准备运行

执行运行

区块滞后是例外。“谁最先公布了这个区块”只有在同一时刻观察所有提供方时才有意义，而且每个区块只是一条很小的消息，因此不会有谁争用你的带宽。

解读结果

什么是 Alchemy rpcbench？

Alchemy rpcbench 是一个单一的二进制文件，在你的机器上、使用你自己的密钥，运行上述完整的方法论。它只向你配置中的端点发送请求，生成的 HTML 报告直接交给你。

我们构建它，是因为把方法论写下来只是容易的那一半。上面的每条规则都需要好几天才能正确实现，而且大多数一旦做错是看不出来的，这对测量工具来说是最糟的组合。

默认配置只是一个起点。workload: 部分可以换成你自己的参数和方法：

速率档位、持续时间、超时和区块滞后窗口同样可以配置，而且在任何负载离开你的机器之前，预检步骤会按请求数、时间和带宽估算这次运行的开销。这个估算以 Alchemy 计算单元（compute units）计，所以把它当作规模检查来看。

每次运行都会写出一个 JSON 文件、CSV 汇总和一个独立的 HTML 仪表盘。它不会给出它无法担保的数字。样本不足、提供方被限流，或者机器跟不上，都会在顶部被标记出来。

通过检查的运行会按以下顺序给你四样东西：

这套方法论不能告诉你什么

• 一个区域的结果不代表另一个区域。如果你的系统运行在别处，就从那里运行。
• 区块滞后是相对于你测试过的最快提供方而言的，而不是相对于真正的链顶端。
• 方法是逐个运行的，因此一次运行永远不是你线上流量组合的重放。
• 一次运行只是一个数据点。我们强烈建议多次运行，以获得关于性能的可靠信号，因为许多因素都可能影响读数，包括全链范围的问题。
• Alchemy rpcbench 工具仅适用于 EVM 网络，每次运行支持一个网络。

如何获取 Alchemy rpcbench？

Alchemy rpcbench 目前处于私有 alpha 阶段。填写此表单申请访问！

如果你更愿意用已有的工具自己搭建，上面的方法论就是全部内容。两种方式我们都乐见，只要你最终据以行动的数字是你自己得出的。

常见问题

我应该如何比较 RPC 提供方？

在你的系统运行的区域，针对它实际调用的方法，对每家提供方运行相同的工作负载。按固定时间表发送，一次测试一家提供方，并固定一个区块，让每家回答同一个问题。逐个方法解读结果，每个延迟数字旁都要列出失败和限流计数，然后在不同时间重复。如果你不想自己搭建，可以联系我们获取 Alchemy rpcbench 的访问权限。

RPC 延迟、区块滞后和数据一致性有什么区别？

延迟是提供方响应你发送的请求所需的时间。区块滞后是它告诉你有新区块所需的时间。数据一致性是在它这样告诉你的那一刻，该区块的日志、收据和交易是否已经可以提供。一家提供方可能三项都强，也可能一项强、另一项落后，这就是它们应该分列的原因。

由提供方构建的基准测试工具，结果可信吗？

可信，而且你不必只听我们的说法。Alchemy rpcbench 中没有任何代码路径会根据所连接的提供方走不同分支，因此针对特定提供方的超时或重试无处隐藏。用 README 中的审计提示词，让任意编程代理检查你克隆的代码，它会替你核查。该工具运行在你的机器上、使用你的密钥，结果永远不会离开你的输出文件夹。

我应该根据单一的综合性能评分来选择 RPC 提供方吗？

不应该。综合评分替你选定了权重，而正确的权重取决于你的应用。回填历史数据的索引器和抢区块的套利机器人，对提供方的需求几乎没有共同之处。读取与你所构建内容相匹配的那个维度，然后逐个方法地读。

应该从哪里运行 RPC 基准测试？

从你的应用运行的区域。RPC 延迟在很大程度上取决于客户端与提供方之间的网络路径，因此从笔记本电脑或从你不部署的云区域运行的基准测试，衡量的是一条你的生产流量永远不会经过的路径。

运行一次 RPC 基准测试需要多长时间？

运行时间取决于你如何配置测试，但默认配置大约需要两个小时。你可以在 10 分钟内完成配置并开始运行测试。Alchemy rpcbench 自带的配置在 Ethereum 上对每家提供方发送 280,000 个请求，覆盖七个方法和三个速率档位，大约需要 48 分钟，区块滞后窗口再加一个小时。提供方轮流测试，因此延迟阶段会随测试的提供方数量增加而变长。预留一个下午，因为置信度需要样本。

对 RPC 提供方做基准测试需要 WebSocket 端点吗？

测延迟不需要。测区块滞后和数据一致性需要，因为两者都依赖 eth_subscribe 和对 newHeads 的订阅。测区块滞后还至少需要两家提供方，因为它衡量的是谁最先公布每个区块。

我可以测试哪些 RPC 提供方？

任何在你所测试的链上提供 EVM JSON-RPC 端点的提供方。URL 和密钥由你提供，方法和工具中没有任何部分取决于提供方是谁。

Alchemy 会发布自己的 RPC 基准测试吗？

会。我们的基准测试页面持续发布提供方对比，现在就可以阅读。Alchemy rpcbench 则用于在你的应用所在的区域、针对你的应用工作负载，得出你自己的结果。