跳至內容

比較主流鏈上的 RPC 效能

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

全域平均回應時間(EVM)

即時

最後更新時間:Sep 25, 2026, 10:33 UTC

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

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

鏈
地區

Average Latency

0.00ms

Alchemy

P50 Latency

0.00ms

Alchemy

P95 Latency

0.00ms

Alchemy

Success Rate

0%

Alchemy

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

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

比較所選鏈與地區之平均延遲、P50 延遲、P95 延遲與成功率的 RPC provider 評比表格。
Provider平均延遲P50 延遲P95 延遲成功率
Alchemy最快
13.98 ms
6.77 ms
30.28 ms
100%
QuickNode
47.29 ms
9.79 ms
207.67 ms
99.99%
dRPC
101.51 ms
21.11 ms
574.54 ms
99.99%
Infura
121.83 ms
104.22 ms
281.75 ms
99.99%

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

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

7.54 ms
13.46 ms
20.13 ms
113.86 ms
  • Alchemy
  • QuickNode
  • dRPC
  • Infura

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

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

0
0
0
4
  • Alchemy
  • QuickNode
  • 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 呼叫,都會轉化為使用者能感受到的延遲:讀取延遲、畫面卡住,以及感覺像出錯的確認流程。選擇能讓你的應用保持順暢運作的基礎架構。