「Solana ShredStream 延遲持續增加」的原因與解決方案

在 ERPC，我們經常收到使用 Solana 實時資料流的客戶回饋：「ShredStream 延遲逐漸增加，最終停止響應。」

本文將清晰解釋此問題發生的主要原因，並提供具體的解決方案來提升您應用的效能。

為什麼 ShredStream 延遲會持續增加？

目前，ShredStream 在未經過濾的情況下傳輸幾乎所有實時資料。因此，如果客戶端的處理能力不足，資料會不斷積累，延遲逐漸增加。

主要原因如下：

1. 使用 Node.js 或單執行緒環境處理

最初，ShredStream 客戶端使用 TypeScript 和 gRPC 協議構建。然而，由於過濾器尚未實現，使用 Node.js 等單執行緒環境很快就會達到處理上限，導致延遲持續上升。

我們確認在同一臺機器上使用 Rust 客戶端時不會出現此問題，從而驗證了單執行緒處理的侷限性。

解決方案：使用 NAPI-RS 實現多執行緒

為此，我們使用 NAPI-RS 技術開發瞭解決方案，在保持 TypeScript 控制的同時實現 Rust 多執行緒處理。該解決方案名為 Solana Stream SDK，已作為開源專案公開發布：

GitHub：ValidatorsDAO/solana-stream

如果您使用 Node.js 或 TypeScript，我們強烈推薦使用此 SDK。為獲得最佳效能，建議使用 Rust 等原生多執行緒語言。

2. 伺服器效能不足（尤其是 CPU 主頻）

使用 Solana ShredStream 的實時流應用通常在 4 核 16GB RAM 的伺服器上可以正常執行。但 CPU 主頻極為重要。較低的主頻可能導致延遲逐漸增加。

以利潤為導向的伺服器通常使用舊一代 CPU 或核心數多但主頻低的 CPU。例如，擁有 84 核的第四代 AMD EPYC CPU 基礎頻率通常約為 2.2GHz，且往往無法有效利用 Turbo 加速。由於 Solana 驗證者的推薦最低要求為 2.8GHz，我們強烈建議客戶也採用至少達到此主頻的 CPU。

此外，VPS 提供商通常使用「超額分配」，即將一臺物理伺服器分割為多個虛擬伺服器。在超額分配的環境中，高峰時段經常與其他使用者發生資源競爭，影響效能。