Solana gRPC 效能：公開的基準測試方法

最後更新：2026年10月21日2 分鐘閱讀

Solana 效能數字的價值，取決於背後的測量方法。一個延遲數字若沒有標明地區、時間區間與測試設定，就無法驗證、比較或重現。

本文記錄我們如何測量 Solana gRPC 串流、公布這些測量產生的數字，並提供完整設定，讓你能對任何端點（包括我們的）重現這項測試。

為什麼要公開測量方法？

單一延遲數字無法告訴你測試在哪裡執行、訂閱了什麼、使用哪個 commitment 等級，或涵蓋多長的時間區間。在 Solana 上，這些細節決定了數字本身：區塊在不到一秒內產出，而各串流端點之間的差距只有幾毫秒。我們已經公開了請求基準測試背後的測量規則；本文則為 Solana 串流做同樣的事。

任何人都能透過發送相同的請求，粗略檢驗請求基準測試。串流則較難檢驗。你無法重播某個時刻的鏈上活動，來確認供應商是否快速、完整且依序地傳送了資料。公開的方法讓開發者能以自己的工作負載重新執行測試，而不必信任任何一方。

這項基準測試測量什麼？

串流效能包含三個獨立的問題：資料何時抵達、是否全部抵達，以及連線中斷時會發生什麼事。這項基準測試回答第一個問題，並依地區分別呈現。

網路往返（p50）。從執行端到端點的 TCP 連線時間中位數，共測量 30 次連線。這主要取決於地理位置，因此能告訴你在任何資料傳輸之前，你所在位置的成本。
傳送落差（p90、p99）。較慢或最差情況的訊息，比該次執行中最快的傳送晚了多少毫秒抵達。長尾正是你的系統在最糟時刻感受到的延遲。如果關鍵的那筆更新晚到，清算監控程式不會在意一般更新有多快。

我們依地區分別回報這兩項數字，從不使用單一的全球平均值。

如何在不信任時鐘的情況下為串流計時？

為請求計時很簡單。同一台機器發送請求並接收回應，因此一個時鐘就能涵蓋整個往返。

串流打破了這種便利。事件起源於驗證者，經過供應商的基礎架構，最後抵達位於另一個資料中心、另一台機器上的訂閱程序。這時牽涉到兩個時鐘，而不同機器上的時鐘即使都執行 NTP，仍可能相差數毫秒。運作良好的端點之間的傳送差距可能比這更小，這代表單純的時間戳記相減，最後測到的可能是時鐘誤差，而不是效能。

我們的端點會在每則訊息上標記其建立時間，執行端再以訊息抵達的時間減去該標記。這個減法比較的是兩個時鐘，因此執行端會在每次執行前後，以公開的時間伺服器校對自己的時鐘。即使如此，仍可能殘留微小的固定誤差。將每則訊息相對於該次執行中最快的傳送來回報，就能消除這個誤差，因為固定的時鐘誤差會讓每則訊息偏移相同的量，在相減時互相抵銷。往返欄位不需要校正，因為執行端是以自己的時鐘為每個 TCP 連線計時。

這些數字無法告訴你從驗證者到你的程序的總時間，也不是用來為供應商排名。排名需要另一種測試：從同一台機器比較兩個串流，重現章節會說明這部分。

有兩個細節讓測量保持誠實。commitment 等級固定為最早的確認等級 processed，因為混用 commitment 等級等於測量事件生命週期中的不同時間點。此外，鏈本身的區塊時間戳記完全不納入計算。Solana 在不到一秒內產出區塊，而區塊時間戳記只精確到秒，太過粗略，無法呈現毫秒級的差距。

一次測試執行是什麼樣子？

本文中的每個數字都來自以下形式的執行。當設定變更時，我們會以新的日期重新公布數字，而不是直接修改原有數字。

受測串流：每次執行使用單一與 Yellowstone 相容的 gRPC 交易串流。
監看帳戶：PumpSwap，也就是 Pump 的 AMM 程式 pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA，因其交易量大而選用。
commitment 等級：每次執行皆為 processed。
樣本數：每個地區 20,000 筆交易。
測量位置：執行端部署在 Fly 機器上，涵蓋六個用戶端地區：美東、美西、歐洲西部、歐洲中部、新加坡與東京。每個執行端到端點的往返時間都是其結果的一部分，因為在咖啡店執行的基準測試，測到的就是咖啡店。
用戶端：geyserbench 中的 Rust latency 範例，使用預設用戶端設定並透過 TLS 連線，詳見下方重現章節。
時間區間：2026 年 10 月 14 日至 16 日。每張公布的表格都會標明產生該數據的執行日期。

結果如何？

以下是從各地區的用戶端測量我們 Solana gRPC 串流的傳送表現。每一列為單一串流在 processed commitment 下的 20,000 筆交易，執行期間為 2026 年 10 月 14 日至 16 日：

地區	p50	p90	p99
美東	1.8 ms	+13.1 ms	+17.4 ms
美西	15.6 ms	+7.2 ms	+12.2 ms
歐洲西部	21.9 ms	+3.5 ms	+14.3 ms
歐洲中部	5.2 ms	+2.4 ms	+6.8 ms
亞太地區，新加坡	4.3 ms	+8.5 ms	+11.7 ms
亞太地區，東京	3.3 ms	+9.2 ms	+23.6 ms

p50 欄位是從執行端到端點的網路往返時間中位數。p90 與 p99 欄位顯示較慢或最差情況的訊息，比該次執行中最快的傳送晚了多少毫秒抵達。

請將 p50 視為你所在位置的距離成本，將 p90 與 p99 視為傳送的穩定程度。兩者都不是從驗證者開始計算的端到端總延遲。評估自身預期的正確方式，是看你所在地區的那一列：法蘭克福的開發者應該看歐洲中部那一列，而不是被測得最快的地區拉低的全球平均值。我們在推出 Solana gRPC 時公布過這項主張的早期版本（從 us-east-1 測量，平均傳送速度比其他方案快 5 到 15ms）。這張表格是該單一地區、直接比較快照的多地區後續版本，採用不同且互補的指標。

如何重現這項測試？

你需要 Rust 與可存取 Solana gRPC 的 Alchemy API 金鑰（先決條件請見快速入門）。只需三個指令：

bashCopied
git clone https://github.com/clinder777/geyserbench && cd geyserbench && git checkout 463cf8e0b70d5b84defb8092e17486eab13960ad
export ALCHEMY_API_KEY=your-alchemy-api-key
cargo run --release --example latency

它會開啟一個 Solana gRPC 串流，在 processed commitment 下監看一個繁忙帳戶上的 20,000 筆交易，並印出到端點的網路往返時間中位數，接著印出你的 p50、p90 與 p99 訊息比最快的傳送晚了多少毫秒抵達。請在你關注的地區的伺服器上執行，並與上方表格比較。

我們使用的是 pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA，也就是 PumpSwap，Pump 的 AMM 程式。它的交易量非常大，20,000 筆交易很快就會抵達，因此是不錯的選擇。若要監看其他程式或執行較短的測試，請將 ACCOUNT 設為程式位址，並將 N 設為交易筆數：

bash

Copied

ACCOUNT=pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA N=5000 cargo run --release --example latency

若要比較兩家供應商，而不是只測量一家，請從同一台機器執行兩個串流，並記錄每筆交易由哪一方先傳送。公開的 geyserbench 可透過列出兩個端點的單一設定檔完成這件事，並回報每個端點先偵測到交易的頻率。

如果你執行後得到的數字與我們的明顯不同，請告訴我們。找出這種差異，正是公開方法的目的。

這項基準測試不測量什麼？

有三件事刻意不在這項基準測試的範圍內：

串流可靠性。這是延遲基準測試。它不測量遺漏的事件、斷線、重新連線時間或重新連線後的回填，因此無法證明或否定這些方面的表現。如果你的應用程式依賴無缺口的傳送，請直接測試。我們的端點保留 48 小時的歷史資料（超過 400,000 個 slot），重新連線的用戶端可以透過 from_slot 從中重播。
交易上鏈。讓交易被納入區塊是寫入路徑的問題，有其專屬的基礎架構與失敗模式。本文內容與此無關。
請求/回應讀取。輪詢 JSON-RPC 方法是不同的存取模式，有不同的失敗模式，我們的公開 RPC 基準測試以其公布的規則另外涵蓋請求流量。

常見問題

Alchemy 的 Solana gRPC 有多快？

這取決於你從哪裡測量，這也是為什麼 Alchemy 公布的是各地區的延遲分布，而不是單一的全球數字。上方的地區表格列出網路往返時間，以及 p90 與 p99 的傳送落差，皆依照公開的方法於標明的日期產生。到端點的網路往返時間從美東的 1.8 ms 到歐洲西部的 21.9 ms 不等，而 p99 訊息會在最快傳送後的 6.8 到 23.6 ms 內抵達，視地區而定。

Solana gRPC 延遲如何測量？

每個地區的用戶端以 processed commitment 開啟一個 gRPC 串流，監看一個高交易量程式上的 20,000 筆交易，並將每則訊息的抵達時間與我們端點建立該訊息的時間比較。結果依地區回報，呈現相對於該次執行中最快傳送的 p90 與 p99 延遲，以及從用戶端到端點的網路往返時間中位數。

我可以重現 Alchemy 的 Solana gRPC 基準測試嗎？

可以。測試使用 geyserbench 中的 latency 範例執行，確切的指令已公布在本文中。請在你提供服務的地區的伺服器上，以 processed commitment 執行，並將你的百分位數與地區表格比較。若要比較兩家供應商，geyserbench 也能從同一台機器並排執行兩個端點。

基準測試使用哪個 commitment 等級？

每次執行都以 Solana 最早的 commitment 等級 processed 訂閱。混用 commitment 等級會在事件生命週期的不同時間點進行測量，讓百分位數失去意義。你的正式環境應用程式可能偏好 confirmed 或 finalized；這套方法固定 commitment 等級，讓數字在各地區與各次執行之間維持可比較性。

這是與其他供應商的比較嗎？

不是。本文記錄的是 Alchemy 如何測量並公布自家 Solana gRPC 的效能。其他供應商也會公布自己的基準測試，而這個領域有更多公開的測量方法，對所有人都有好處。重現章節的存在，是為了讓你能以自己的工作負載，親自執行真正重要的比較。

開始串流 Solana 資料

我們的 Solana gRPC 串流與 Yellowstone 相容，因此讓現有用戶端指向它只需要更換 URL，不需要重寫程式碼。定價為每 TB $75，沒有每月最低消費，快速入門請參考 Yellowstone gRPC 文件。在 Solana 上開發的團隊也可以透過 2,000 萬美元 Solana Fund 申請最高 25,000 美元的額度。想先執行基準測試也可以，這正是它存在的目的。