Waarom blijft mijn Solana ShredStream-latentie toenemen? Oorzaken en oplossingen

Bij ERPC ontvangen wij regelmatig vragen van klanten die Solana's realtimedatastream gebruiken, met de melding dat "de ShredStream-latentie geleidelijk toeneemt en de stream uiteindelijk stopt."

In dit artikel leggen wij duidelijk de belangrijkste redenen uit waarom dit probleem optreedt en bieden wij concrete oplossingen om de prestaties van uw applicatie te verbeteren.

Momenteel verzendt ShredStream vrijwel alle realtimedata zonder filters. Hierdoor stapelt data zich op als de verwerkingscapaciteit van de client onvoldoende is, waardoor de latentie geleidelijk toeneemt.

De voornaamste oorzaken zijn als volgt:

Aanvankelijk was de ShredStream-client gebouwd met TypeScript en het gRPC-protocol. Omdat filters echter nog niet zijn geïmplementeerd, bereikt het gebruik van een single-threaded omgeving zoals Node.js snel verwerkingslimieten, waardoor de latentie continu stijgt.

Wij hebben vastgesteld dat dit probleem niet optreedt bij gebruik van een Rust-client op dezelfde machine, wat de beperking van single-threaded verwerking bevestigt.

Als reactie hierop hebben wij een oplossing ontwikkeld met NAPI-RS-technologie, die multithreaded verwerking in Rust mogelijk maakt met behoud van besturing vanuit TypeScript. Deze oplossing, bekend als Solana Stream SDK, is open-source en publiekelijk beschikbaar:

Als u Node.js of TypeScript gebruikt, raden wij het gebruik van deze SDK sterk aan. Voor maximale prestaties kunt u overwegen een native multithreaded taal zoals Rust te gebruiken.

Realtimestream-applicaties die Solana ShredStream gebruiken, functioneren doorgaans adequaat op een server met 4 cores en 16 GB RAM. CPU-kloksnelheid is echter extreem belangrijk. Lagere kloksnelheden kunnen leiden tot geleidelijk toenemende latentie.

Servers die bedoeld zijn om winst te maximaliseren gebruiken vaak CPU's van oudere generaties of CPU's met veel cores maar lage kloksnelheden. Bijvoorbeeld: vierde generatie AMD EPYC CPU's met veel cores (zoals modellen met 84 cores) hebben doorgaans een basisklok van circa 2,2 GHz en benutten turbo boost vaak niet effectief. Aangezien de aanbevolen minimumvereiste voor Solana-validators 2,8 GHz is, adviseren wij klanten sterk ook CPU's met minimaal deze kloksnelheid te kiezen.

Daarnaast gebruiken VPS-providers veel "overcommitment," een praktijk waarbij één fysieke server in meerdere virtuele servers wordt verdeeld. In een omgeving met overcommitment is er tijdens piektijden regelmatig concurrentie met andere gebruikers om middelen, wat de prestaties negatief beïnvloedt.

ERPC biedt VPS-servers uitgerust met de nieuwste generatie AMD EPYC CPU's met kloksnelheden tot 4,15 GHz. Deze servers leveren prestaties die dicht bij bare-metaloplossingen liggen, perfect geschikt voor Solana-workloads die realtimedatastreams vereisen.

Voorheen waren VPS-oplossingen met hoge kloksnelheden niet beschikbaar, waardoor gebruikers die realtimeprestaties nodig hadden gedwongen waren bare-metalservers te kiezen. ERPC's VPS-aanbod lost deze beperking op.

ERPC's VPS-oplossingen zijn geoptimaliseerd voor Solana's realtimedatastreaming en worden zeer geprezen door veel high-frequency traders en projecten.

Deze oplossingen zijn ideaal voor klanten die hoge prestaties nodig hebben zonder de capaciteit van een volledige bare-metalserver nodig te hebben.

Wij moedigen u aan onze VPS-oplossingen te proberen.

Voor gratis proefperiodes of uitgebreid advies, bezoek de officiële Discord-server van Validators DAO:

ERPC blijft zich inzetten voor voortdurend onderzoek en ontwikkeling om aan uw veranderende behoeften te voldoen en verbeterde prestaties te ondersteunen.

Dank voor uw voortdurende steun.