«Perché la latenza del mio ShredStream Solana continua ad aumentare»: cause e soluzioni

In ERPC riceviamo frequentemente richieste da clienti che utilizzano lo stream di dati in tempo reale di Solana, che segnalano che «la latenza dello ShredStream aumenta gradualmente e alla fine si blocca».

In questo articolo, spiegheremo chiaramente le ragioni principali per cui si verifica questo problema e offriremo soluzioni concrete per migliorare le prestazioni della tua applicazione.

Attualmente, lo ShredStream trasmette quasi tutti i dati in tempo reale senza filtri. Per questo motivo, se le capacità di elaborazione del client sono insufficienti, i dati si accumulano, aumentando gradualmente la latenza.

Le cause principali sono le seguenti:

Inizialmente, il client ShredStream era costruito con TypeScript e il protocollo gRPC. Tuttavia, poiché i filtri non sono ancora implementati, l’uso di un ambiente a thread singolo come Node.js raggiunge rapidamente i limiti di elaborazione, causando un aumento continuo della latenza.

Abbiamo verificato che questo problema non si verifica utilizzando un client Rust sulla stessa macchina, confermando così il limite dell’elaborazione a thread singolo.

In risposta, abbiamo sviluppato una soluzione che utilizza la tecnologia NAPI-RS, consentendo l’elaborazione multi-thread in Rust mantenendo il controllo da TypeScript. Questa soluzione, nota come Solana Stream SDK, è open-source e disponibile pubblicamente:

Se usi Node.js o TypeScript, consigliamo vivamente di utilizzare questo SDK. Per le massime prestazioni, considera l’uso di un linguaggio multi-thread nativo come Rust.

Le applicazioni di streaming in tempo reale che utilizzano Solana ShredStream funzionano generalmente in modo adeguato su un server con 4 core e 16 GB di RAM. Tuttavia, la frequenza di clock della CPU è estremamente importante. Frequenze di clock più basse possono portare a una latenza che aumenta gradualmente.

I server pensati per massimizzare il profitto spesso utilizzano CPU di generazioni precedenti o CPU con molti core ma basse frequenze di clock. Ad esempio, le CPU AMD EPYC di quarta generazione con molti core (come i modelli a 84 core) hanno tipicamente un clock base di circa 2,2 GHz e spesso non sfruttano efficacemente il turbo boost. Poiché il requisito minimo raccomandato per i validator Solana è 2,8 GHz, consigliamo vivamente anche ai clienti di adottare CPU con almeno questa frequenza di clock.

Inoltre, i provider VPS utilizzano comunemente l’«overcommitment», una pratica che consiste nel dividere un server fisico in più server virtuali. In un ambiente con overcommitment, la competizione per le risorse con altri utenti si verifica frequentemente nei momenti di picco, con un impatto negativo sulle prestazioni.

ERPC fornisce server VPS equipaggiati con le più recenti CPU AMD EPYC con frequenze di clock fino a 4,15 GHz. Questi server offrono prestazioni vicine alle soluzioni bare-metal, perfettamente adatte ai carichi di lavoro Solana che richiedono stream di dati in tempo reale.

In precedenza, non esistevano soluzioni VPS ad alta frequenza di clock, costringendo gli utenti che necessitavano di prestazioni in tempo reale a scegliere server bare-metal. L’offerta VPS di ERPC risolve questa limitazione.

Le soluzioni VPS di ERPC sono ottimizzate per lo streaming di dati in tempo reale di Solana e sono molto apprezzate da numerosi trader ad alta frequenza e progetti.

Queste soluzioni sono ideali per i clienti che necessitano di alte prestazioni senza richiedere le risorse di un server bare-metal.

Ti invitiamo a provare le nostre soluzioni VPS.

Per prove gratuite o consulenze dettagliate, visita il Discord ufficiale di Validators DAO:

ERPC rimane impegnata nella ricerca e nello sviluppo continui per soddisfare le tue esigenze in evoluzione e supportare il miglioramento delle prestazioni.

Grazie per il tuo continuo supporto.