--- title: "Solana gRPC 效能：公開的基準測試方法" description: "我們如何在六個地區測量 Solana gRPC 的傳送延遲，附上 p50、p90 與 p99 結果、完整的測試設定，以及重現結果的確切指令。" --- # Solana gRPC 效能：公開的基準測試方法 Solana 效能數字的價值，取決於背後的測量方法。一個延遲數字若沒有標明地區、時間區間與測試設定，就無法驗證、比較或重現。本文記錄我們如何測量 [Solana gRPC 串流](https://www.alchemy.com/solana-grpc)、公布這些測量產生的數字，並提供完整設定，讓你能對任何端點（包括我們的）重現這項測試。 ## 為什麼要公開測量方法？單一延遲數字無法告訴你測試在哪裡執行、訂閱了什麼、使用哪個 commitment 等級，或涵蓋多長的時間區間。在 Solana 上，這些細節決定了數字本身：區塊在不到一秒內產出，而各串流端點之間的差距只有幾毫秒。我們已經公開了[請求基準測試背後的測量規則](https://www.alchemy.com/blog/how-we-benchmark-rpc-performance)；本文則為 Solana 串流做同樣的事。任何人都能透過發送相同的請求，粗略檢驗請求基準測試。串流則較難檢驗。你無法重播某個時刻的鏈上活動，來確認供應商是否快速、完整且依序地傳送了資料。公開的方法讓開發者能以自己的工作負載重新執行測試，而不必信任任何一方。 ## 這項基準測試測量什麼？串流效能包含三個獨立的問題：資料何時抵達、是否全部抵達，以及連線中斷時會發生什麼事。這項基準測試回答第一個問題，並依地區分別呈現。 - **網路往返（p50）**。從執行端到端點的 TCP 連線時間中位數，共測量 30 次連線。這主要取決於地理位置，因此能告訴你在任何資料傳輸之前，你所在位置的成本。 - **傳送落差（p90、p99）**。較慢或最差情況的訊息，比該次執行中最快的傳送晚了多少毫秒抵達。長尾正是你的系統在最糟時刻感受到的延遲。如果關鍵的那筆更新晚到，清算監控程式不會在意一般更新有多快。我們依地區分別回報這兩項數字，從不使用單一的全球平均值。 ## 如何在不信任時鐘的情況下為串流計時？為請求計時很簡單。同一台機器發送請求並接收回應，因此一個時鐘就能涵蓋整個往返。串流打破了這種便利。事件起源於驗證者，經過供應商的基礎架構，最後抵達位於另一個資料中心、另一台機器上的訂閱程序。這時牽涉到兩個時鐘，而不同機器上的時鐘即使都執行 NTP，仍可能相差數毫秒。運作良好的端點之間的傳送差距可能比這更小，這代表單純的時間戳記相減，最後測到的可能是時鐘誤差，而不是效能。我們的端點會在每則訊息上標記其建立時間，執行端再以訊息抵達的時間減去該標記。這個減法比較的是兩個時鐘，因此執行端會在每次執行前後，以公開的時間伺服器校對自己的時鐘。即使如此，仍可能殘留微小的固定誤差。將每則訊息相對於該次執行中最快的傳送來回報，就能消除這個誤差，因為固定的時鐘誤差會讓每則訊息偏移相同的量，在相減時互相抵銷。往返欄位不需要校正，因為執行端是以自己的時鐘為每個 TCP 連線計時。這些數字無法告訴你從驗證者到你的程序的總時間，也不是用來為供應商排名。排名需要另一種測試：從同一台機器比較兩個串流，重現章節會說明這部分。有兩個細節讓測量保持誠實。commitment 等級固定為最早的確認等級 `processed`，因為混用 commitment 等級等於測量事件生命週期中的不同時間點。此外，鏈本身的區塊時間戳記完全不納入計算。Solana 在[不到一秒](https://www.alchemy.com/blog/zero-downtime-zero-gaps-solana-grpc-streaming)內產出區塊，而區塊時間戳記只精確到秒，太過粗略，無法呈現毫秒級的差距。 ## 一次測試執行是什麼樣子？本文中的每個數字都來自以下形式的執行。當設定變更時，我們會以新的日期重新公布數字，而不是直接修改原有數字。 - **受測串流**：每次執行使用單一與 Yellowstone 相容的 gRPC 交易串流。 - **監看帳戶**：PumpSwap，也就是 Pump 的 AMM 程式 `pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA`，因其交易量大而選用。 - **commitment 等級**：每次執行皆為 `processed`。 - **樣本數**：每個地區 20,000 筆交易。 - **測量位置**：執行端部署在 [Fly](https://fly.io/) 機器上，涵蓋六個用戶端地區：美東、美西、歐洲西部、歐洲中部、新加坡與東京。每個執行端到端點的往返時間都是其結果的一部分，因為在咖啡店執行的基準測試，測到的就是咖啡店。 - **用戶端**：geyserbench 中的 Rust `latency` 範例，使用預設用戶端設定並透過 TLS 連線，詳見下方重現章節。 - **時間區間**：2026 年 10 月 14 日至 16 日。每張公布的表格都會標明產生該數據的執行日期。 ## 結果如何？以下是從各地區的用戶端測量我們 Solana gRPC 串流的傳送表現。每一列為單一串流在 processed commitment 下的 20,000 筆交易，執行期間為 2026 年 10 月 14 日至 16 日： p50 欄位是從執行端到端點的網路往返時間中位數。p90 與 p99 欄位顯示較慢或最差情況的訊息，比該次執行中最快的傳送晚了多少毫秒抵達。請將 p50 視為你所在位置的距離成本，將 p90 與 p99 視為傳送的穩定程度。兩者都不是從驗證者開始計算的端到端總延遲。評估自身預期的正確方式，是看你所在地區的那一列：法蘭克福的開發者應該看歐洲中部那一列，而不是被測得最快的地區拉低的全球平均值。我們在[推出 Solana gRPC](https://www.alchemy.com/blog/introducing-alchemy-solana-grpc) 時公布過這項主張的早期版本（從 us-east-1 測量，平均傳送速度比其他方案快 5 到 15ms）。這張表格是該單一地區、直接比較快照的多地區後續版本，採用不同且互補的指標。 ## 如何重現這項測試？你需要 Rust 與可存取 Solana gRPC 的 Alchemy API 金鑰（先決條件請見[快速入門](https://www.alchemy.com/docs/reference/yellowstone-grpc-quickstart)）。只需三個指令：它會開啟一個 Solana gRPC 串流，在 processed commitment 下監看一個繁忙帳戶上的 20,000 筆交易，並印出到端點的網路往返時間中位數，接著印出你的 p50、p90 與 p99 訊息比最快的傳送晚了多少毫秒抵達。請在你關注的地區的伺服器上執行，並與上方表格比較。我們使用的是 `pAMMBay6oceH9fJKBRHGP5D4bD4sWpmSwMn52FMfXEA`，也就是 PumpSwap，Pump 的 AMM 程式。它的交易量非常大，20,000 筆交易很快就會抵達，因此是不錯的選擇。若要監看其他程式或執行較短的測試，請將 `ACCOUNT` 設為程式位址，並將 `N` 設為交易筆數：若要比較兩家供應商，而不是只測量一家，請從同一台機器執行兩個串流，並記錄每筆交易由哪一方先傳送。公開的 [geyserbench](https://github.com/hmstudio-labs/geyserbench) 可透過列出兩個端點的單一設定檔完成這件事，並回報每個端點先偵測到交易的頻率。如果你執行後得到的數字與我們的明顯不同，請告訴我們。找出這種差異，正是公開方法的目的。 ## 這項基準測試不測量什麼？有三件事刻意不在這項基準測試的範圍內： - **串流可靠性**。這是延遲基準測試。它不測量遺漏的事件、斷線、重新連線時間或重新連線後的回填，因此無法證明或否定這些方面的表現。如果你的應用程式依賴無缺口的傳送，請直接測試。我們的端點保留 48 小時的歷史資料（超過 400,000 個 slot），重新連線的用戶端可以透過 `from_slot` 從中重播。 - **交易上鏈**。讓交易被納入區塊是寫入路徑的問題，有其專屬的基礎架構與失敗模式。本文內容與此無關。 - **請求/回應讀取**。輪詢 JSON-RPC 方法是不同的存取模式，有不同的失敗模式，我們的[公開 RPC 基準測試](https://www.alchemy.com/benchmarks)以其公布的規則另外涵蓋請求流量。 ## 常見問題 ### 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 串流](https://www.alchemy.com/solana-grpc)與 Yellowstone 相容，因此讓現有用戶端指向它只需要更換 URL，不需要重寫程式碼。定價為每 TB $75，沒有每月最低消費，快速入門請參考 [Yellowstone gRPC 文件](https://www.alchemy.com/docs/reference/yellowstone-grpc-overview)。在 Solana 上開發的團隊也可以透過 [2,000 萬美元 Solana Fund](https://www.alchemy.com/solana-20m-fund) 申請最高 25,000 美元的額度。想先執行基準測試也可以，這正是它存在的目的。