跳至內容

比較主流鏈上的 RPC 效能

查看各 provider 在延遲、成功率與失敗請求數上的表現,所有測試皆在相同條件下進行。

全域平均回應時間(EVM)

即時

最後更新時間:Sep 4, 2026, 23:28 UTC

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

在目前 EVM 鏈的全域 24 小時評比中,Alchemy 的平均回應時間最低,為 16.02 ms。

地區

Average Latency

0.00ms

Alchemy

P50 Latency

0.00ms

Alchemy

P95 Latency

0.00ms

Alchemy

Success Rate

0.00%

Alchemy

所有已評比的鏈(所有地區)的 provider 比較

在此 24 小時檢視中,Alchemy 的平均延遲最低,為 16.02 ms。表格同時顯示每個 provider 的 P50、P95 與成功率。

比較所選鏈與地區之平均延遲、P50 延遲、P95 延遲與成功率的 RPC provider 評比表格。
Provider平均延遲P50 延遲P95 延遲成功率
Alchemy最快
16.02 ms
6.47 ms
43.82 ms
99.87%
QuickNode
56.10 ms
9.78 ms
232.25 ms
100%
Infura
112.07 ms
104.25 ms
277.96 ms
99.88%
dRPC
114.58 ms
24.40 ms
555.12 ms
99.96%

各方法平均延遲:所有已評比的鏈,所有地區

選擇一個方法,查看各 provider 處理該請求類型的速度。

9.48 ms
15.43 ms
20.45 ms
113.66 ms
  • Alchemy
  • QuickNode
  • dRPC
  • Infura

各方法失敗請求數:所有已評比的鏈,所有地區

選擇一個方法,查看各 provider 的錯誤與逾時集中在哪裡。

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

方法論

受控的 RPC 測試,透明的規則

這些是方法層級的 EVM 讀取評比。我們從相同地區發送相同的設定 payload,將速度與可靠性分開衡量,並公開規則以方便解讀數字。

Payload icon

相同 payload

每個方法都會讓每個 provider 收到相同的設定 JSON-RPC payload、鏈、地區、逾時時間與成功標準。

Regions icon

共用執行地區

測試分別在 US East、US West、EU Central 與 AP Southeast 執行,每個 provider 都在相同的執行地點測試。

Accounts icon

標準付費帳號

每個 provider 都以標準付費 RPC 服務帳號進行測試,不使用特殊路由、方案、重試或特別待遇。

Latency icon

成功回應延遲

延遲數據使用已預熱、重複使用的 HTTP 連線,且僅計入成功的回應。失敗會另外統計。

Failure rules icon

明確的失敗規則

HTTP 錯誤、JSON-RPC 錯誤、解析失敗、網路錯誤、速率限制與 8 秒逾時,皆計為失敗。

Scope icon

方法層級範圍

此評比衡量個別讀取請求,不包含完整應用流程、寫入、WebSockets、冷啟動或自訂流量組合。

供 agent 使用的評比資料

以文字表格形式開啟所有評比檢視畫面,包含欄位定義與來源中繼資料,專為 agent、爬蟲與想直接取得資料的開發者設計。

開啟 Markdown 資料

常見問題

評比常見問題

即時 RPC 評比如何運作、衡量哪些項目,以及在哪裡取得原始資料。

  • 追蹤 Alchemy、QuickNode、dRPC 與 Infura 在常見 EVM JSON-RPC 讀取方法上的成功回應延遲(平均值、P50 與 P95)、成功率與失敗請求數。
  • 評比請求每 10 秒執行一次,全天候不間斷。公開頁面與 Markdown 資料路徑每 5 分鐘更新一次,顯示最新的 24 小時區間。
  • 評比在 US East、US West、EU Central 與 AP Southeast 執行。全域檢視會彙整這四個地區的結果。
  • 比較的是標準付費 RPC 服務帳號。每個 provider 都收到相同的設定方法、payload、鏈、地區、逾時時間與成功標準,沒有特別待遇。
  • 若請求回傳非 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 讀取效能。不衡量完整應用程式流程、寫入交易、WebSockets、客戶特定的流量組合、冷連線建立,或所有可能的鏈、provider、地區、方法與 payload 組合。

延遲是使用者要承擔的成本

每一次緩慢的 RPC 呼叫,都會轉化為使用者能感受到的延遲:讀取延遲、畫面卡住,以及感覺像出錯的確認流程。選擇能讓你的應用保持順暢運作的基礎架構。