跳至内容

比较主流链上的 RPC 性能

查看各提供商在相同条件下测试的延迟、成功率和失败请求数对比。

全球平均响应时间（EVM）

实时

最后更新：Sep 4, 2026, 23:39 UTC

Alchemy0.00 ms
QuickNode0.00 ms
Infura0.00 ms
dRPC0.00 ms

在当前全球 24 小时 EVM 链基准测试中，Alchemy 的平均响应时间最低，为 16.02 ms。

链
地区

Average Latency

0.00ms

Alchemy

P50 Latency

0.00ms

Alchemy

P95 Latency

0.00ms

Alchemy

Success Rate

0.00%

Alchemy

所有地区 地区 所有已测试的链 链的提供商对比

在此 24 小时视图中，Alchemy 的平均延迟最低，为 16.02 ms。表格还显示了每个提供商的 P50、P95 和成功率。

RPC 提供商基准测试表格，比较所选链和地区的平均延迟、P50 延迟、P95 延迟和成功率。
提供商平均延迟P50 延迟P95 延迟成功率
Alchemy最快
16.02 ms
6.47 ms
43.82 ms
99.87%
QuickNode
56.11 ms
9.78 ms
232.25 ms
100%
Infura
112.07 ms
104.25 ms
277.96 ms
99.88%
dRPC
114.57 ms
24.39 ms
555.17 ms
99.96%

按方法划分的平均延迟：所有已测试的链，所有地区

选择一种方法，查看各提供商处理该请求类型的速度。

9.48 ms
15.42 ms
20.44 ms
113.66 ms
  • Alchemy
  • QuickNode
  • dRPC
  • Infura

按方法划分的失败请求：所有已测试的链，所有地区

选择一种方法，查看各提供商的错误和超时集中在哪里。

2
78
110
777
  • QuickNode
  • Alchemy
  • dRPC
  • Infura

测试方法

受控 RPC 测试，规则透明

这些是方法级别的 EVM 读取基准测试。我们从相同地区发送相同配置的请求负载，将速度与可靠性区分开，并公开测试规则，便于理解这些数据。

查看完整测试方法
Payload icon

相同请求负载

对于每种方法，所有提供商都使用相同配置的 JSON-RPC 请求负载、链、地区、超时时间和成功判定标准。

Regions icon

共用测试运行地区

测试从美国东部、美国西部、欧洲中部和亚太东南地区运行，所有提供商均在同一运行位置进行测试。

Accounts icon

标准付费账户

所有提供商均使用标准付费 RPC 服务账户进行测试，不使用特殊路由、套餐、重试机制或其他特殊处理。

Latency icon

成功响应延迟

延迟数据基于预热并复用的 HTTP 连接，仅统计成功响应，失败请求单独记录。

Failure rules icon

明确的失败判定规则

HTTP 错误、JSON-RPC 错误、解析失败、网络错误、速率限制以及超过 8 秒的超时均计为失败。

Scope icon

方法级别范围

该基准测试衡量单个读取请求，不涉及完整应用流程、写入操作、WebSocket、冷启动或自定义流量组合。

面向 agent 的基准数据

将每个基准视图打开为带字段定义和来源元数据的文本表格，专为需要原始数据而非界面的 agent、爬虫和开发者设计。

打开 Markdown 数据

常见问题

基准测试常见问题

实时 RPC 基准测试的工作原理、测量内容，以及原始数据的获取方式。

  • 这些测试跟踪 Alchemy、QuickNode、dRPC 和 Infura 在常见 EVM JSON-RPC 读取方法上的成功响应延迟（平均值、P50 和 P95）、成功率以及失败请求数。
  • 基准测试请求全天每 10 秒运行一次。公开页面和 Markdown 数据接口每 5 分钟刷新一次最新的 24 小时数据窗口。
  • 基准测试在美国东部、美国西部、欧洲中部和亚太东南地区运行。“全球”视图汇总了这四个地区的结果。
  • 这些测试比较的是标准付费 RPC 服务账户。所有提供商均使用相同配置的方法、请求负载、链、地区、超时时间和成功判定标准，不做任何特殊处理。
  • 如果请求返回非 2xx 的 HTTP 状态码、返回 JSON-RPC 错误对象、超过 8 秒超时、在网络层失败，或无法解析为有效 JSON，均视为失败。速率限制响应也计为失败。
  • 延迟是运行器在预热并复用的连接上，测量成功的 JSON-RPC HTTP POST 请求从发出到收到响应所用的时间。失败请求和超时不计入延迟，而是计入成功率。
  • 不使用。每次请求只有一次尝试机会，失败即计入失败次数，而不会重试，因此成功率反映的是应用实际需要处理的失败情况。
  • 实时基准测试覆盖 Ethereum、Optimism、Arbitrum、Base 和 World Chain，另有一个汇总当前所有测试链的“总览”视图。

  • 该基准测试涵盖以下配置的 EVM 读取测试：

    • eth_getBalance: 账户余额查询
    • eth_getBlockByNumber: 最早区块，链起始处的区块头读取
    • eth_getBlockByNumber: 最新区块，链头处的区块头读取
    • eth_getLogs: 1 个区块范围
    • eth_getLogs: 10 个区块范围
    • eth_getLogs: 100 个区块范围
    • eth_getLogs: Ethereum 上 1,000 个区块范围
    • eth_getTransactionReceipt: 单笔交易回执查询
  • 可以。配套的 Markdown 页面以文本表格形式发布结果，包含字段定义、来源元数据和按链、按地区划分的完整数据集。
  • P95 展示的是成功响应中较慢的部分：在该方法、链、地区和时间窗口内，95% 的成功请求都在此延迟或更短时间内完成。应结合成功率一起看，因为只有请求真正返回时，快速响应才有意义。
  • 这些测试衡量的是受控条件下、预热状态下单一方法的 EVM 读取性能，不衡量完整应用流程、写入交易、WebSocket、客户特定的流量组合、冷连接建立过程，也不涵盖所有可能的链、提供商、地区、方法和请求负载。

延迟是对用户的一种损耗

每一次缓慢的 RPC 调用都会转化为用户能感知到的卡顿：读取延迟、界面卡死、确认过程像是出了故障。选择能让应用保持流畅运行的基础设施。

开始构建联系我们