Waarom Mijn Solana ShredStream-latentie Blijft Toenemen - Oorzaken en Oplossingen

Bij ERPC ontvangen wij regelmatig vragen van klanten die Solana's realtimedata-stream gebruiken, die stellen dat "ShredStream-latentie geleidelijk toeneemt en 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 16GB 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 oudere generatie CPU's of CPU's met veel cores maar lage kloksnelheden. Bijvoorbeeld: vierde generatie AMD EPYC CPU's met veel cores (zoals 84-core modellen) hebben doorgaans een basisklok van circa 2,2GHz en benutten turbo boost vaak niet effectief. Aangezien de aanbevolen minimumvereiste voor Solana validators 2,8GHz is, adviseren wij klanten sterk ook CPU's met minimaal deze kloksnelheid te adopteren.

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

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

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

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

Deze oplossingen zijn ideaal voor klanten die hoge prestaties nodig hebben zonder de middelen van een bare-metal server te vereisen.

Wij moedigen u aan onze VPS-oplossingen te proberen.

Voor gratis proefperiodes of gedetailleerde consultaties, bezoek de officiële Discord van Validators DAO:

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

Dank voor uw voortdurende steun.