RPC 基准方法论

从 benchmark 服务器测量

延迟在后端 benchmark 服务中测量，而不是在访问者的浏览器中测量。计时会在 benchmark 服务器发送 HTTP RPC 请求前立即开始，并在收到并解析响应后结束。

往返响应时间

测得的值是 RPC 往返时间：从 benchmark 服务器到提供商的网络传输、提供商处理时间，以及响应返回的网络传输。只有当你的应用运行在相似区域时，这个值才接近应用会看到的延迟。

成功延迟与失败分开计算

只有成功样本会用于 p50、p95、p99、平均延迟、抖动和最大延迟。失败请求会单独计入错误率、超时率、方法兼容性和 findings。

相同请求编号，相同方法

两个端点会收到同一条生成的请求序列。如果第 18 个请求对你的端点是 `eth_getBlockByNumber`，那么第 18 个请求对 GetBlock 也是 `eth_getBlockByNumber`。这种成对模式保证了按方法对方法比较。

方法级结论

方法级结论会对比两个提供商上的相同方法。如果一侧完全没有成功响应而另一侧成功，该方法会被标记为该提供商失败。如果一侧错误率或超时率很高，则会标记为不稳定。否则由 p95 决定胜负；如果差异低于 10%，则记为相近。

提供商评分

提供商评分综合平均延迟、p95、p99、成功率、超时率和协议感知的 freshness。评分会敏感反映延迟差异，但可靠性仍然重要：一个很快但大量失败的端点不应被视为生产就绪。这个分数不是协议标准，而是这个工具使用的紧凑比较信号。

生产就绪标签

生产就绪标签基于测得结果生成。示例包括方法兼容性问题、陈旧节点风险、高超时风险、可能限流、快速且稳定、较慢但可靠、表现相近等。这个标签的目标是概括最可能在真实使用中先出问题的地方。

可执行发现

可执行发现基于明确的基准证据生成，并在报告中按照“问题 → 为什么重要 → 下一步怎么做”的结构呈现。重复出现的 HTTP 429 会形成限流发现，401/403 会形成访问受阻发现，高超时率会形成超时风险发现，方法级失败会形成兼容性发现，高抖动会形成一致性发现，而区块滞后会形成区块新鲜度发现。