Solana VPS versus Bare Metal: CPU, UDP en netwerktests

Waarom de server net zo belangrijk is als de Solana-stream

Een snelle Solana-datastroom garandeert niet dat een toepassing de data op tijd kan gebruiken. Een lage CPU-belasting en een geadverteerde 1Gbps-poort verklaren onvolledige ontvangst niet. Meet de volledige keten van bron tot toepassing. We gebruiken geanonimiseerde onderzoeken en openbare metingen zonder een niet-bewezen oorzaak aan een provider toe te schrijven.

Snelheid betekent ook veel en soms piekende data

Shreds en Yellowstone Geyser gRPC leveren continu data, soms in korte pieken. Bandbreedte, pakketten per seconde (PPS), RTT, jitter, verlies en verwerkingstijd zijn verschillende grootheden. Een hypothetische 4 MB/s gedurende 30 dagen is 10,4 TB, maar gemiddeld slechts 32 Mbps. Dat bewijst niet dat 1 Gbps onvoldoende is. Controleer UDP-beleid, piekbelasting, gedeelde uplinks en ontvangers.

De stream werkt, maar de fragmenten ontbreken

In een anoniem onderzoek werden bij de zender circa 3.400–3.900 UDP-pakketten/s gezien; op een ander moment meldde een ontvanger circa 13 pakketten/s. De ontvangen Shreds waren geldig maar onvoldoende voor reconstructie. gRPC werkte op dezelfde host. Omdat tijdstippen en meetpunten afweken, is dit geen berekende verliesratio en geen vastgestelde oorzaak. Enkele duizenden PPS zijn voor een gewone server niet op zichzelf uitzonderlijk.

Meet eerst waar de pakketten zichtbaar zijn

Een upstream-netwerkbeleid, DDoS-beveiliging of virtualisatiehost kan UDP vóór de gastmachine beperken. Na de NIC kunnen kernel, socketbuffer en app ook pakketten laten vallen. Begin met tcpdump op de bedoelde interface; vergelijk NIC-tellers, UDP-fouten en wachtrijen. XDP kan vóór tcpdump droppen. Gebruik dezelfde poort, bestemming en tijdvensters voor beide kanten.

Dezelfde stad kan een omweg betekenen

Twee systemen in Frankfurt kunnen verschillende datacenters en netwerken gebruiken en via extern transit lopen. Vanaf één externe host werd naar twee dicht bij elkaar liggende Amsterdam-endpoints ongeveer 11 en 23 ms RTT gemeten, terwijl de endpoints onderling circa 0,1 ms verwijderd waren. In een andere periode waren er 5–8% verlies en ongeveer 5 ms extra vertraging op het upstream-pad. Dit zegt niets over alle providers.

Draai toepassingen naast de databron

Een RPC-provider levert doorgaans de data en een hostingbedrijf de server. ERPC ontwerpt Shreds, Geyser gRPC, RPC, VPS en Bare Metal gezamenlijk. Op geschikte locaties kunnen bron en app via een kort lokaal netwerkpad tussen nabijgelegen racks communiceren. Zero-Distance Communication betekent geen letterlijke nul latentie of garantie; meet het werkelijke pad. Een privé-IP is niet per definitie sneller.

Vergelijk wat werkelijk binnenkomt

Bij een vergelijkbaar Geyser-gRPC-abonnement op hetzelfde Amsterdam-endpoint ontving een externe host 3,7–4,2 MiB/s met oplopende lag. Een onafhankelijke ERPC Frankfurt VPS-proef op één CPU-core haalde gemiddeld 9,396 MiB/s en ongeveer 1.910 transacties/s gedurende 60 seconden zonder oplopende lag. Op de probleemroute waren TCP-hertransmissies zichtbaar. Host en clientversie verschilden: geen gecontroleerde A/B-test en geen gegarandeerde ERPC-versnelling. Een aparte HTTP/2-test gaf 2,7 MB/s met 16 KiB receive window tegenover maximaal 7,1 MB/s met een groter venster.

Een CPU-naam verbergt werkelijke limieten

VM's met dezelfde CPU-generatie en vCPU-aantallen kunnen ander boost-, stroom-, koelings- en schedulingbeleid hebben. AMD Core Performance Boost en Intel Turbo Boost kunnen op host- of BIOS-niveau uit staan. AAN betekent niet dat de piekklok onbeperkt houdbaar is. De gast ziet hostbeleid soms niet. Meet langdurige prestaties onder de echte belasting.

Vier vCPU's: 1,93× in een gepubliceerde benchmark

ERPC's benchmark van AMD Turin-systemen met vier vCPU's en Ubuntu 24.04 in Amsterdam meldt 7.850 tegenover 4.062 sysbench CPU-events/s, circa 1,93× voor die test. Ook genoemd zijn circa 3,2× geheugenbandbreedte en 16,6× 4K willekeurige lees-IOPS. Dit bewijst niet dat boost het enige verschil veroorzaakte of dat elke app dezelfde winst behaalt.

Datacentereconomie bepaalt technische keuzes

Stroom, koeling, racks, switches, uplinks en beheer kosten geld. Capaciteit delen en energie sparen is rationeel voor veel reguliere toepassingen. Intensieve Solana-stromen en realtime-verwerking kunnen langdurig hoge CPU-, PPS- en netwerkcapaciteit vragen. Gedeelde bandbreedte, per-flow-limieten en DDoS-regels zijn niet per se slechte keuzes, maar moeten passen bij je workload.

Vergeet de datatransferkosten van de cloud niet

Doorlopende streams verzamelen veel terabytes. Internet-ingress is bij sommige clouds gratis, maar uitgaand verkeer en verkeer tussen zones of diensten kan kosten. Geschikte ERPC-producten behandelen intern platformverkeer apart van externe datalimieten volgens actuele voorwaarden. Vergelijk de totale kosten van het datapad in plaats van alleen de VM-prijs.

Kies VPS of Bare Metal op basis van gebruik

Voor lichte RPC kan een EPYC VPS volstaan. Voortdurende gRPC-analyse vraagt voldoende CPU en geheugen; Shreds UDP en realtime-apps vereisen geschikt UDP-beleid, PPS, piekruimte en lage detectielatentie. Bare Metal geeft exclusieve fysieke middelen maar is niet automatisch sneller voor alles. Soms werken meerdere VPS'en beter. Meet dezelfde software, filters en tijdvensters, geldige Shreds, reconstructie, lag, hertransmissies en p95/p99.

Meet voordat je langdurig vastlegt

Met Linux-tools tcpdump, nstat, ip -s link, ethtool -S, ss -tin en lscpu kun je read-only beginnen. Vervang voorbeeld-IP en interface en vergelijk tellerveranderingen. lscpu toont niet betrouwbaar het boostbeleid van de hypervisor. ERPC biedt voor geschikte VPS/Bare Metal-opties uurbetaling afhankelijk van voorraad. Kies de server die de nodige data tijdig bruikbaar maakt.

bash

IFACE=ens3
SRC_IP=203.0.113.10  # documentation address; replace with real sender IP
PORT=2000
sudo timeout -s INT 10 tcpdump -nni "$IFACE" -l -q \
  "udp and src host $SRC_IP and dst port $PORT" 2>/dev/null | wc -l
nstat -az UdpInErrors UdpRcvbufErrors
ip -s link show dev "$IFACE"
sudo ethtool -S "$IFACE" | grep -Ei 'drop|miss|err|fifo'
ss -tin
lscpu

IFACE=ens3
SRC_IP=203.0.113.10  # documentation address; replace with real sender IP
PORT=2000
sudo timeout -s INT 10 tcpdump -nni "$IFACE" -l -q \
  "udp and src host $SRC_IP and dst port $PORT" 2>/dev/null | wc -l
nstat -az UdpInErrors UdpRcvbufErrors
ip -s link show dev "$IFACE"
sudo ethtool -S "$IFACE" | grep -Ei 'drop|miss|err|fifo'
ss -tin
lscpu