ERPC

「Solana 資料延遲或不完整？」接收端基礎設施該檢查什麼

「Solana 資料延遲或不完整？」接收端基礎設施該檢查什麼

「Solana 資料延遲或不完整？」接收端基礎設施該檢查什麼
訂閱了高速 Solana Shreds 串流，卻只收到零星封包。收到的 Shreds 可以正確解析，但缺少太多片段，無法擷取交易。同一台伺服器上的 gRPC 卻能正常運作，讓您不知道接下來該查哪裡。
在檢查傳送端的同時，也應檢查應用程式伺服器及其所在的資料中心。即使 ERPC 很快就轉發了 Shreds，路徑上的 UDP 限制，或接收伺服器的處理瓶頸，也可能讓您的應用程式無法受益於這樣的速度。
選擇 Shreds 串流時，需要考量完整路徑：封包如何抵達，以及如何轉化為可用的資料。網路品質、距離與資料中心的維運政策，也是 Geyser Yellowstone gRPC、一般 RPC 與 API 流量，以及交易提交共同依賴的效能條件。
從 ERPC 的高速 Shreds 傳送，經過接收端資料中心與應用程式伺服器，到可用資料的概念路徑圖，分別呈現網路限制與伺服器內部的處理瓶頸。

傳送端紀錄與接收後可用的資料，反映的是不同的事實

在最近的一次 ERPC 支援諮詢中，傳送端的短時間量測記錄了約 3,400–3,900 packets/sec。接收端則回報約 13 packets/sec，且未完成任何 slot 重建。
這些數值來自不同的量測時段，且尚未確認量測方法是否具有可比性。因此，它們無法用來判定送達成功率或丟包率。僅憑傳送端紀錄並不能證明資料已抵達；截至本文撰寫時，最終原因仍未確定。
每秒幾千個封包本身，也不足以認定這對一般用途伺服器屬於異常高的負載。需要確認的是實際路徑上發生什麼事、適用哪些限制、流量如何在短時間內集中、接收如何處理，以及每個計數器實際量測什麼。

同在法蘭克福，網路路徑也可能不同

您的串流來源與應用程式伺服器可能都位於法蘭克福，卻仍分屬不同的資料中心。在這種配置下，流量可能會離開其中一座設施，經過外部網路，再進入另一座設施。區域標籤相同，並不代表位於同一座設施、使用相同的網路業者或經過相同的一組中間設備。
當 ERPC 串流或 RPC 服務與 ERPC VPS 或 Bare Metal 主機部署在同一個站點時，服務伺服器與應用程式伺服器會位於鄰近的機櫃中，兩者之間的通訊在內部網路完成。這正是 ERPC「零距離通訊」的概念：除了選擇同一座城市，還要一併設計實體部署位置與通往接收應用程式的路徑。
概念對照圖：一側是跨越法蘭克福不同資料中心、經過外部網路的路徑，另一側是 ERPC 在同一站點內，使用鄰近機櫃與內部路徑的配置。圖示涵蓋用於 Shreds、Yellowstone gRPC、RPC 與交易提交的 ERPC 服務及應用程式伺服器。
避免 ERPC 服務與應用程式伺服器之間繞行外部網路，可以縮短路徑，並降低這一段通訊受外部網路壅塞與路由變動影響的程度。較短的路徑，搭配接收與處理所需的資源，是發揮高速串流優勢的基礎。請分別在封包抵達與應用程式處理兩個階段驗證結果。

網路條件影響各種通訊

在 Shreds 中，片段缺失讓問題變得明顯，但同一基礎架構的品質，也會更廣泛地影響資料接收、API 請求與交易提交。協定不同，應用程式看到的症狀與值得量測的環節也會不同。
通訊類型網路影響出現在哪裡在應用程式中檢查什麼
Shreds / UDP封包遺失與延遲，以及重建所需片段的抵達情況有效 Shreds，以及資料能夠完成重建所需的時間
Geyser Yellowstone gRPCTCP 重傳等待、串流積壓與延遲接收並處理同一筆更新所需的時間
RPC、API 與服務間流量請求與回應的往返，以及壅塞期間的等待回應時間及其變動
交易提交請求送達接收節點的路徑從發出提交請求到節點回應的時間
鄰近部署與合適的維運政策能支援上述各類流量。接收節點的回應時間，應與交易被納入區塊並在鏈上最終確認所需的時間分開量測。

僅看 Gbps，無法掌握 PPS 與突發流量的全貌

頻寬描述單位時間內可傳輸的資料量。PPS 則描述每秒處理的封包數量。連線即使還有剩餘頻寬，也可能觸及封包速率上限，或受到針對 UDP 的限制。雲端供應商本身的文件，也將頻寬與 PPS 配額視為不同的限制條件。[1]
Shreds 不一定以均勻的速率抵達。突發流量可能造成平均值無法顯示的佇列壓力。若封包累積的速度超過網路設備或接收端的處理速度，超出佇列容量的封包就可能遭到丟棄。[2]
請向主機服務供應商確認持續接收 UDP、短時間突發流量、PPS 限制，以及 DDoS 防護所套用的規則。目的是建立可安全接納必要流量的條件，而不是不加區分地停用防護。

gRPC 正常運作，不代表 UDP 接收也正常

以 TCP 為基礎的 gRPC，與透過 UDP 傳送的原始 Shreds，使用不同的傳輸機制。TCP 提供重傳與排序機制，而 gRPC 串流具有考量接收端處理能力的流量控制機制。UDP 本身不會重傳遺失的封包，也不會要求傳送端等待接收應用程式趕上進度。[3]
因此，伺服器上的 gRPC 可以正常運作，並不能證明 UDP 路徑或接收端也運作正常。必須分別檢查各協定專屬的篩選規則、連接埠、傳送路徑與接收端實作。gRPC 處理延遲也可能表現為等待時間增加或連線中斷。
gRPC 的 transactions/sec 與 UDP 的 packets/sec，在不同處理階段量測的是不同單位。不能直接比較兩者來計算送達量或遺失率。

從封包抵達，到資料可用

採用標準 UDP 通訊端接收時，抵達的封包會先經過網路介面卡（NIC）、核心與通訊端接收緩衝區，再送到應用程式。如果處理速度跟不上，封包即使已抵達主機，仍可能遭到丟棄。Linux 介面接收計數器包含之後階段遭到丟棄的封包，因此僅憑接收計數增加，並不能證明封包已交付應用程式。[4]
即使整體 CPU 使用率偏低，個別接收佇列或 CPU 核心仍可能十分忙碌。請檢查 NIC 佇列、中斷配置與單核心效能。在應用程式中，應視情況將接收與後續工作分開，避免在接收迴圈中進行耗費大量資源的解析或過量的日誌輸出。較大的接收緩衝區可以吸收暫時的突發流量，但無法解決持續處理能力不足的問題。[5]
Shreds 是區塊資料的片段。前向錯誤更正（FEC）能利用同一組中的 data shreds 與 coding shreds 復原遺失的資料，但重建仍需要足夠的片段。增加重複封包的數量，不能取代缺少的片段。[6]
依實作方式而定，接收端可以在整個 slot 完成之前，利用現有片段重建 entries。[9] 除了封包總數，也要量測不重複的有效 Shreds、重建出的資料，以及應用程式辨識所需事件所花的時間。

在相同時間區間內，逐一量測各個階段

請對齊兩端的目的地、連接埠與量測時間區間。分別記錄下列階段，有助於縮小下一步調查範圍。
量測位置記錄內容可以判定什麼
傳送端針對目標目的地的紀錄與計數器定義觀察到了哪個傳送階段
接收主機入口目標 UDP 流量的封包擷取、NIC 統計與擷取時的丟包該觀測點可見的流量有多少
作業系統與通訊端UDP 錯誤、接收緩衝區丟包與佇列變化主機內部的接收是否出現積壓
Shreds 重建不重複的有效 Shreds、成功重建情況、遺失資料與錯誤能否由封包取得所需資料
應用程式處理積壓，以及偵測同一事件的時間戳記封包抵達的速度是否反映在應用程式中
若封包擷取結果只顯示少量封包，請先檢查擷取的篩選條件、觀察的介面、擷取時的遺失，以及 NIC 丟包。有些作業系統計數器涵蓋整台主機或整個網路命名空間；請確認其範圍，並將其與目標應用程式的量測結果對照。[4][5]
找出受到限制的階段後，再調整設定。單純增大緩衝區或環形佇列，可能會轉移瓶頸，或增加等待時間。ERPC 目前的接收端設定與檢查方式，記載於以下文件：
https://erpc.global/zh-tw/doc/shredstream/udp-forwarding/

選擇伺服器時，也要選擇維運政策

Solana Foundation 說明了對高效能驗證節點而言，能夠控制 NIC、實體核心、驅動程式與網路的重要性。不應將完整驗證節點的需求全盤套用到每一個 Shreds 接收端。接收應用程式需要的是適合自身串流與處理工作負載的配置。[7]
降低成本或耗電量，是合理的維運目標。HFT 與即時應用程式同時也需要 CPU 迅速回應、持續的處理能力，以及較短的網路等待時間。從省電狀態喚醒，可能涉及延遲方面的取捨。[8]
除了 CPU 型號與核心數，還要檢查資源如何共用、如何處理持續負載、UDP 流量的適用條件，以及實際的網路路徑。

ERPC 一併考量串流與接收環境

ERPC 從鄰近 Solana 基礎架構的資料中心選址、網路路徑、硬體與維運設定著手，除了 Shreds 與 gRPC，也提供 VPS 與 Bare Metal。您可以依處理工作負載選擇 VPS，並在需要獨占實體資源時，將 Bare Metal 納入比較。
瞭解我們所提供環境的配置與運作方式，也有助於技術問題排查。我們可以對照傳送端紀錄與接收端量測，找出網路、作業系統或應用程式的具體檢查項目。在本文提到的諮詢案例中，我們檢查了傳送端量測結果，並請接收端補充量測。
一併評估串流、接收端部署位置與應用程式實作，有助於釐清從您所選服務到所需資料之間，還缺少哪些條件。

透過按小時計費，與目前環境進行比較

如果您對接收環境仍有疑問，可以透過按小時計費使用 ERPC VPS 或 Bare Metal 伺服器，以相同的串流與應用程式進行比較。請在控制台確認所需區域的目前價格、可用資源與訂購條件。
從可用的配置開始，記錄接收數量、重建出的資料、處理積壓，以及偵測相同事件的時間戳記。跨主機比較時間戳記時，也請檢查時鐘同步的精確度。在不同時段重複測試，比較路徑中哪些位置的結果不同，再依據這些量測結果，選擇適合應用程式的伺服器與資料中心。

相關文章

技術參考資料

下一頁

ERPC 發布 Solana Stream SDK v4.0.0，加速 UDP Shreds 處理與 gRPC 連線恢復

新聞

ERPC 發布 Solana Stream SDK v4.0.0，加速 UDP Shreds 處理與 gRPC 連線恢復

ERPC 發布 Solana Stream SDK v4.0.0，加速 UDP Shreds 處理與 gRPC 連線恢復

ERPC Edge 提供涵蓋 Solana、Ethereum 等 16 條鏈的多鏈 RPC，一組 RPC 金鑰即可使用

ERPC Edge 提供涵蓋 Solana、Ethereum 等 16 條鏈的多鏈 RPC，一組 RPC 金鑰即可使用

ERPC 擴展 Unlimited Endpoints：一份訂閱使用 Solana、Ethereum 與 Avalanche 高速 RPC

ERPC 擴展 Unlimited Endpoints：一份訂閱使用 Solana、Ethereum 與 Avalanche 高速 RPC