我們如何評測 RPC 效能

基準測試數字很容易被引用,也很容易被誤讀。RPC 效能尤其如此。一張延遲圖表可能隱藏了好幾個不同的問題:請求從哪裡發出、執行了哪個方法、送出了什麼負載、什麼算成功、失敗如何處理,以及測試的是一次 RPC 呼叫還是完整的應用程式流程。

我們建立了公開的 EVM 讀取基準測試,目的就是要讓這些細節變得可見。目標是在受控、可重複的測試環境下,呈現各家供應商之間的比較結果。

我們的基準測試回答的問題是:在選定的鏈、地區與時間區間內,各家供應商在常見 EVM JSON-RPC 讀取方法上的表現如何比較。

這些是方法層級的基礎設施基準測試:針對每個方法、鏈、供應商與地區,分別執行一套受控的方法論。它們量測的是個別的 RPC 請求,而不是完整的應用程式流程,例如載入錢包投資組合、準備一筆 swap,或是跨多次呼叫輪詢交易狀態。這個區別很重要:方法層級的結果有助於開發者比較供應商的行為,但它們並不是任何正式應用程式的完整模型。

什麼是 Alchemy 的公開 EVM 讀取基準測試?

Alchemy 的公開 EVM 讀取基準測試是一項受控測試,用來量測 RPC 供應商對設定好的 EVM JSON-RPC 讀取請求的回應方式。它會記錄成功回應的延遲(平均值、p50、p95)、成功率,以及失敗請求數量,並依供應商、鏈、方法、地區與時間區間分組呈現。

我們只針對成功回應計算延遲。失敗的嘗試與逾時則另外透過成功率與失敗請求數量追蹤。這樣可以讓基準測試同時聚焦在速度與可靠性上,而不是把兩者混為一談單獨看待。

定義與量測規則

以下是本文其餘部分所依據的定義、設定與規則。每一列的內容會在下方章節中進一步說明。

基準測試涵蓋哪些範圍?

這項基準測試涵蓋 Ethereum、Optimism、Arbitrum、Base 與 World Chain 主網,公開的供應商清單包括 Alchemy、dRPC、Infura 與 QuickNode。我們選擇這些對象是為了涵蓋廣泛使用的 EVM 主網,以及開發者最常評估的 RPC 供應商,並保留日後擴充範圍的空間。對於某個方法,每家供應商都會收到相同設定的 JSON-RPC 請求。

我們從受控的 AWS ECS 地區執行每項測試:美國東部、美國西部、歐洲中部與亞太東南部。在同一個地區內,每家供應商都是從相同的執行器位置進行測試,因為網路距離會影響延遲。如果我們用維吉尼亞州測試某家供應商,又用新加坡測試另一家,結果反映的就會是地理因素而不是供應商的效能。

每項結果依以下條件分組:

• 供應商
• 鏈
• 方法
• 地區
• 移動時間區間

基準測試送出什麼內容給每家供應商?

方法(method)指的是被呼叫的操作,例如 eth_getBalance 或 eth_getLogs。負載(payload)則是我們送出以執行該方法的完整請求內容,包括其參數。這個區別很重要,因為效能同時取決於兩者:一次低成本的查詢與一次大範圍的掃描,對供應商造成的負載截然不同,而即使是同一個方法,也會因輸入內容不同而有所變化。

對於某個方法,每家供應商都會在標準付費帳號下收到相同設定的 JSON-RPC 負載。這就是公平性的原則:相同的方法、相同的參數、相同的鏈、相同的地區、相同的逾時設定、相同的成功判定標準,任何供應商都沒有特殊待遇。

目前這代表在大多數鏈上有七項設定好的測試,而在 Ethereum 上則有八項:

• eth_getBalance:帳戶餘額查詢
• eth_getBlockByNumber(earliest 區塊):讀取鏈起始處的區塊標頭
• eth_getBlockByNumber(latest 區塊):讀取鏈頭的區塊標頭
• eth_getLogs:1 個區塊範圍
• eth_getLogs:10 個區塊範圍
• eth_getLogs:100 個區塊範圍
• eth_getLogs:1,000 個區塊範圍(僅限 Ethereum)
• eth_getTransactionReceipt:單筆交易收據查詢

有些負載會隨著鏈的狀態變動。舉例來說,使用 latest 區塊標籤的呼叫,會隨著鏈的推進而改變。其他則使用固定的歷史輸入值:Ethereum 上的 eth_getLogs 測試,使用的是針對 LINK 代幣合約設定好的固定歷史區塊範圍。

這樣的組合是刻意設計的:

• 固定輸入值讓部分測試具有可重複性。
• 移動輸入值讓部分測試能反映即時的鏈上狀態。
• 固定的歷史輸入值可能較容易被供應商快取。

RPC 效能可能會因方法、參數、區塊範圍、回應大小、快取行為與鏈上狀態不同而有很大差異。在閱讀基準測試結果時,請聚焦在最接近你自己工作負載的方法與參數上。

效能是如何量測的?

我們透過兩項訊號來量測效能,各自回答不同的問題:延遲,即成功回應返回的速度有多快(以平均值、p50 與 p95 呈現);以及成功率,即請求整體成功的頻率有多高(背後有失敗請求數量作為佐證)。

這兩者相關但不同:一次快速的成功回應,並不等同於一次可靠的回應。我們將兩者並列呈現,避免其中一項掩蓋另一項。

延遲是如何量測的?

延遲指的是執行器針對一次成功的 JSON-RPC HTTP POST 所量測到的請求與回應時間。計時器在執行器送出請求時開始,在收到回應時停止。如果某家供應商在 120 毫秒內回傳有效回應,該次請求的延遲就是 120 毫秒。

我們使用預熱過、可重複使用的 HTTP 連線。簡單來說,我們並沒有計入開啟新連線所需的初始設定步驟,例如 DNS 查詢、TCP 連線建立,或 TLS 交握。執行器會先預熱連線,然後才在一個共用的 keep-alive 連線上量測 POST 本身。

這樣一來,延遲數字就更接近重複性應用程式流量的情況,因為客戶端通常會重複使用連線。但這也表示,你不應該把這些數字解讀為冷啟動首次請求的延遲。

只有成功的回應會被納入延遲分布。如果請求逾時、回傳 HTTP 錯誤、回傳 JSON-RPC 錯誤物件、解析失敗,或發生網路錯誤,我們會將其計為失敗的嘗試。

逾時不會被當作 8,000 毫秒的緩慢回應處理。我們會將其排除在延遲計算之外,並計入成功率當中,藉此讓延遲專注於回應速度,成功率則專注於可靠性。

什麼是成功率?

成功率是指在基準測試規則下,成功返回的請求佔所有嘗試請求的比例:成功請求數除以總嘗試請求數。

一次請求只有在以下條件全部成立時才算成功:

1. 在基準測試的逾時時間內完成。
2. 回傳 HTTP 2xx 狀態碼。
3. 回應內容可解析為 JSON。
4. JSON-RPC 回應中不包含非空值的 error 物件。

我們不會用重試來掩蓋失敗的嘗試。每一次嘗試請求只有一次機會。如果失敗,就會被計入。

基準測試如何處理逾時?

基準測試執行器最多會等待 8 秒,等待每家供應商回傳有效回應。如果在時限內沒有收到有效回應,我們會將該次嘗試記錄為逾時失敗。

這 8 秒的截止時間是我們測試設定的一部分。它並非由鏈本身決定,也不是供應商內部可能使用的任何逾時設定。

目前所有公開的 EVM 讀取方法都適用這個 8 秒的截止時間。某個特定方法理論上可以設定不同的逾時時間,但目前並沒有任何方法這麼做。

什麼算是失敗的請求?

我們會將失敗的嘗試與延遲分開追蹤。如果一次請求發生以下任一情況,就會被計為失敗:

• 回傳非 2xx 的 HTTP 狀態碼,例如 403、429、500、502、503 或 504
• 回傳 JSON-RPC 錯誤物件
• 8 秒後逾時
• 在網路層級失敗,或
• 無法解析為有效的 JSON

速率限制的回應也算作失敗,而且我們從不使用重試把失敗的嘗試轉變成成功的結果。每一次失敗都會降低該供應商的成功率,並累加到該方法、鏈、地區與時間區間的失敗請求數量中。

這些指標是如何定義的?

為什麼要把延遲與成功率放在一起呈現?

只有在回應真的能夠返回時,快速的回應才有意義。有些供應商在成功的請求上可能顯示出很低的延遲,但同時逾時或失敗的頻率也比較高,因此我們會將延遲與成功率並列呈現:延遲顯示有效回應返回的速度,成功率顯示回應整體返回的頻率。

舉例來說,如果我們送出 1,000 次嘗試,其中 990 次在 8 秒逾時之前成功返回,成功率就是 99%。這 10 次失敗的嘗試不會被計入 p50、p95 或平均延遲,而是會反映在可靠性的失敗數字上。

這樣可以避免兩種誤讀:延遲低但失敗較多的供應商,不應該只憑速度來評判;成功率高但尾端延遲較慢的供應商,也不應該只憑可靠性來評判。

為什麼基準測試使用移動時間區間?

基準測試會持續執行。常見的公開 EVM 讀取方法大約每 10 秒執行一次,而我們每 5 分鐘就會根據過去 24 小時的移動時間區間,更新一次公開基準測試頁面。

在完全正常運作的情況下,一個每 10 秒執行一次的方法,每天會針對每個供應商、方法、網路與地區產生大約 8,640 次嘗試。移動的 24 小時時間區間讓每個公開數字都有足夠的樣本數,可以平滑掉偶發的異常波動,同時維持頁面資訊的即時性。

因此,請把公開頁面上的數字視為一個滾動更新的每日總結,而不是單一次請求、一次性測試,或某個瞬間的快照。

基準測試不量測哪些內容?

目前,這項基準測試量測的是受控條件下、單一方法的暖連線讀取效能。它並不量測:

• 多次呼叫組成的使用者流程
• 寫入交易或交易送出
• WebSocket 或訂閱行為
• 特定客戶的請求組合
• 冷啟動首次請求的連線建立
• 每一家供應商、每一條鏈、每一個地區、每一個方法或每一種負載形式
• 你自己的架構、流量水準或部署地理位置的實際行為

正是這個範圍界線,讓這項基準測試變得有用:它告訴你這些數字適用於哪些情況,以及你應該在哪些情況下自行執行符合自身工作負載的測試。

速度與可靠性是相關但不同的問題:

• 速度問的是成功請求返回的速度有多快。
• 可靠性問的是請求整體成功返回的頻率有多高。

我們在設計這項基準測試時,刻意呈現這個區別,而不是把它們壓縮成單一的「最快供應商」這種說法。

開發者應該如何使用這些結果?

把公開基準測試當作評估供應商的起點。以下是一種實用的閱讀方式:

1. 選出最接近你工作負載的鏈與方法。
2. 比較最符合你使用者或基礎設施所在位置的地區。
3. 查看 p95,而不只是平均值或 p50。
4. 將成功率與延遲一併檢視。
5. 如果你的工作負載使用不同的負載內容、更高的並發量、寫入操作、WebSocket,或多次呼叫的流程,在做出決定之前,請先執行符合你自身工作負載的基準測試。

透明的基準測試能幫助你提出更好的問題。它們讓你更容易看清楚測試了什麼、計算了什麼、排除了什麼,以及結果中哪些部分對實際應用程式最為重要。

常見問題

什麼是 Alchemy 的公開 EVM 讀取基準測試?

這是一項受控測試,用來量測 RPC 供應商如何處理常見的 EVM JSON-RPC 讀取請求。它會記錄成功回應的延遲(平均值、p50、p95)、成功率,以及失敗請求數量,涵蓋選定的供應商、鏈、方法與地區,讓開發者能在相同、可重複的條件下比較供應商,而不是依賴行銷宣傳。

RPC 延遲是如何量測的?

延遲是執行器針對一次 JSON-RPC POST 及其回應、在預熱過且重複使用的連線上所量測到的實際時間。計時器在請求送出時開始,在收到有效回應時停止。只有成功的回應會被計入,因此延遲反映的是回應速度,而不是連線建立或失敗的情況。

什麼算是成功的請求?

一次請求只有在 8 秒逾時時間內返回、回傳 HTTP 2xx 狀態碼、可解析為 JSON,且不包含 JSON-RPC 錯誤物件時,才算成功。其他情況,包括逾時、HTTP 錯誤與速率限制回應,都會被計為失敗的嘗試,並排除在延遲計算之外。

基準測試如何處理逾時?

執行器最多會等待 8 秒,等待有效回應返回。如果時限內沒有收到回應,該次嘗試會被記錄為逾時失敗,而不是視為 8,000 毫秒的緩慢回應。逾時會降低成功率,但絕不會拉高延遲數字,藉此讓速度與可靠性維持為各自獨立的量測指標。

基準測試會使用重試嗎?

不會。每次量測都是單一次嘗試。如果該次嘗試失敗,失敗就會被計入,而不會透過重試來掩蓋。這樣可以確保成功率如實反映情況,因為重試會掩蓋掉實際應用程式真正會遇到的間歇性失敗。

基準測試涵蓋哪些鏈與供應商?

公開的基準測試涵蓋 Ethereum、Optimism、Arbitrum、Base 與 World Chain 主網。供應商清單包括 Alchemy、dRPC、Infura 與 QuickNode。針對某個方法,每家供應商都會從相同的地區,在相同的逾時設定與成功判定規則下,收到相同設定的請求。

基準測試測試哪些 RPC 方法?

這項基準測試執行七項設定好的讀取測試,建構自四個 EVM 方法:eth_getBalance;eth_getBlockByNumber(最早與最新區塊);eth_getLogs(1、10 與 100 個區塊範圍);以及 eth_getTransactionReceipt。Ethereum 額外加上一項 1,000 個區塊範圍的 eth_getLogs 測試,共計八項。每一項都使用固定的負載,以確保各供應商之間的結果具有可比較性。

基準測試不量測哪些內容?

它不量測完整的應用程式流程、寫入交易、WebSocket 訂閱、特定客戶的流量組合,或冷連線建立。它也未涵蓋所有的鏈、供應商、地區、方法或負載形式。針對這些情況,請執行符合你自身流量的工作負載專屬基準測試。

我該如何解讀 p95 延遲數字?

可以這樣理解 p95:在特定的方法、鏈、地區與時間區間內,95% 的成功回應至少有這麼快。它揭露了平均值會掩蓋的尾端行為。請務必將它與成功率一併檢視,因為只有在回應真的能夠返回時,快速的回應才有意義。