Solana VPS e Bare Metal: CPU, UDP, benchmark di rete

Perché il server conta quanto lo stream Solana

Uno stream Solana veloce non garantisce che i dati siano disponibili in tempo nell'applicazione. Una CPU poco occupata e una porta dichiarata da 1 Gbps non spiegano necessariamente una ricezione incompleta. Bisogna esaminare l'intero percorso. Questa guida riunisce osservazioni tecniche anonimizzate, test indipendenti e benchmark pubblicati senza attribuire responsabilità a un operatore in assenza di prove.

Alta velocità significa anche grandi flussi di dati

Shreds e Yellowstone Geyser gRPC possono inviare dati in modo continuo con raffiche improvvise. Banda, pacchetti al secondo (PPS), RTT, jitter, perdita e tempi di elaborazione sono misure distinte. Un flusso ipotetico di 4 MB/s per 30 giorni vale circa 10,4 TB ma mediamente solo 32 Mbps. Questo non prova che 1 Gbps sia insufficiente: contano anche limiti UDP, raffiche, uplink condivisi e ricezione.

Lo stream funziona, ma mancano i frammenti

In un'indagine anonimizzata la sorgente registrava circa 3.400–3.900 pacchetti UDP/s; in un altro momento venivano segnalati circa 13 pacchetti/s al ricevitore. Gli Shreds erano validi ma insufficienti alla ricostruzione. Sullo stesso host funzionava gRPC. Le osservazioni provengono da finestre e punti diversi: non determinano una percentuale di perdita né una causa. Alcune migliaia di PPS non sono di per sé un carico impossibile per un server normale.

Individuare il punto di misura prima di cambiare macchina

Policy di rete, protezione DDoS e host di virtualizzazione possono limitare UDP a monte. Dopo la scheda NIC, kernel, buffer socket e applicazione possono perdere altri pacchetti. Prima catturare sulla NIC con tcpdump, poi controllare contatori ed errori UDP e la coda dell'applicazione. XDP può eliminare pacchetti prima di tcpdump. Confrontare mittente e destinatario nello stesso intervallo, senza attribuzioni affrettate.

Vicinanza geografica e percorso di rete non coincidono

Due host a Francoforte possono trovarsi in strutture diverse e attraversare reti esterne. Da un host remoto sono stati misurati circa 11 ms e 23 ms RTT verso due endpoint vicini ad Amsterdam, con circa 0,1 ms tra loro. In un'altra fascia oraria il percorso upstream registrava perdite del 5–8% e circa 5 ms di latenza aggiuntiva. Sono risultati di percorsi specifici, non di tutti i provider.

Mettere l'esecuzione vicino alla sorgente

Di solito il fornitore RPC offre i dati e l'hosting offre i server. ERPC progetta insieme Shreds, Geyser gRPC, RPC, VPS e Bare Metal. Nelle sedi supportate, sorgente e server applicativo possono comunicare tramite rete locale tra rack vicini, evitando deviazioni esterne superflue. Zero-Distance Communication non implica distanza o latenza letteralmente nulle. Va sempre misurato il percorso effettivo.

Misurare i dati che arrivano davvero

Su una sottoscrizione Geyser gRPC comparabile allo stesso endpoint di Amsterdam, un host esterno osservava 3,7–4,2 MiB/s con ritardo crescente. Un test indipendente da VPS ERPC a Francoforte, limitato a un core, ha registrato in media 9,396 MiB/s e circa 1.910 transazioni/s per 60 secondi senza accumulo di ritardo. Sul percorso problematico risultavano ritrasmissioni TCP. Host e implementazioni erano diversi: non è un test A/B controllato. Un test HTTP/2 separato ha misurato 2,7 MB/s con finestra 16 KiB e fino a 7,1 MB/s con una finestra più ampia.

Il nome della CPU nasconde i limiti reali

VM con la stessa generazione CPU e lo stesso numero di vCPU possono avere impostazioni diverse per boost, potenza, raffreddamento e scheduling. AMD Core Performance Boost e Intel Turbo Boost possono essere disattivati nel BIOS o nell'host. Anche quando attivi non garantiscono il clock massimo continuo. La VM potrebbe non vedere la policy dell'host. Si misura il rendimento sostenuto sotto carico reale.

Quattro vCPU, differenza misurata di 1,93×

Nel benchmark ERPC pubblicato tra sistemi AMD Turin a quattro vCPU con Ubuntu 24.04 ad Amsterdam, sysbench CPU ha registrato 7.850 contro 4.062 eventi/s, circa 1,93× in quel test. Sono riportate inoltre differenze di circa 3,2× nella banda memoria e 16,6× nelle IOPS casuali in lettura 4K. Questi dati non garantiscono lo stesso risultato per ogni applicazione e non isolano il boost come unica causa.

L'economia del data center condiziona le scelte

Energia, raffreddamento, rack, switch, connettività e manutenzione hanno costi reali. Condividere le risorse è sensato per i carichi comuni. Stream Solana impegnativi e applicazioni a bassa latenza possono invece richiedere clock, PPS e banda sostenuti. Uplink condivisi, limiti per flusso, protezione DDoS e risparmio energetico possono essere scelte adatte ad altri clienti. Conta la compatibilità con il proprio lavoro, non una condanna del provider.

Considerare anche il costo del traffico cloud

Stream continui accumulano terabyte nel tempo. L'ingresso da Internet è spesso gratuito nei grandi cloud, mentre uscita, trasferimenti tra zone e servizi possono essere fatturati. I prodotti ERPC idonei distinguono il traffico interno alla piattaforma dalle quote esterne, secondo il piano corrente. Valutare il costo dell'intero percorso e non soltanto il canone della VM.

Scegliere VPS o Bare Metal in base all'uso

Un EPYC VPS può bastare per RPC leggero; analisi gRPC continuativa richiede riserve CPU e memoria. Shreds UDP e trading a bassa latenza richiedono policy UDP adatte, PPS, gestione delle raffiche e tempi di rilevamento stabili. Bare Metal offre risorse fisiche esclusive ma non è automaticamente più rapido per ogni app; distribuire il carico tra VPS può essere utile. Confrontare software, filtri e finestre uguali, Shreds validi, ricostruzione, lag, ritrasmissioni e latenze p95/p99.

Misurare prima di impegnarsi

Su Linux si possono usare tcpdump, nstat, ip -s link, ethtool -S, ss -tin e lscpu per controlli iniziali in sola lettura. Sostituire interfaccia e IP di esempio e misurare gli incrementi. lscpu da solo non rivela la policy boost dell'hypervisor. ERPC offre fatturazione oraria su VPS e Bare Metal idonei secondo disponibilità. Scegliere il server che rende utilizzabili i dati nel tempo necessario.

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