「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 核 16 GB RAM 的伺服器上可以正常執行。但 CPU 時脈極為重要。較低的時脈可能導致延遲逐漸增加。

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

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