«I dati Solana sono lenti o incompleti?» Cosa controllare nell’infrastruttura di ricezione
Ti abboni a un flusso veloce di Shreds Solana, ma arrivano solo pochi pacchetti. Gli Shreds che ricevi vengono analizzati correttamente, eppure mancano troppi frammenti per estrarre le transazioni. gRPC funziona sullo stesso server e non sai quali altre verifiche fare.
Oltre a controllare il mittente, esamina il tuo server applicativo e il data center che lo ospita. Anche quando ERPC inoltra rapidamente gli Shreds, le restrizioni UDP lungo il percorso o i colli di bottiglia nell’elaborazione sul server ricevente possono impedire alla tua applicazione di sfruttare quella velocità.
Scegliere un flusso di Shreds significa considerare l’intero percorso: come arrivano i pacchetti e come diventano dati utilizzabili. Qualità della rete, distanza e politiche operative del data center sono inoltre condizioni di prestazione comuni a Geyser Yellowstone gRPC, al normale traffico RPC e API e all’invio delle transazioni.
I registri di invio e i dati ricevuti utilizzabili rappresentano fatti diversi
In una recente richiesta di assistenza a ERPC, brevi misurazioni sul lato mittente hanno registrato circa 3.400–3.900 pacchetti/s. Il ricevitore ha segnalato circa 13 pacchetti/s e nessuna ricostruzione completa di uno slot.
Queste cifre derivano da periodi di misurazione differenti e non è stato confermato che i metodi di misurazione siano confrontabili. Non consentono quindi di stabilire un tasso di consegna riuscita o un tasso di perdita. I soli registri lato mittente non dimostrano l’arrivo dei pacchetti e, al momento della stesura, la causa definitiva rimane indeterminata.
Qualche migliaio di PPS, inoltre, non basta da solo a stabilire che un server di uso generale sia sottoposto a un carico insolitamente elevato. Occorre capire cosa succede sul percorso effettivo, quali limiti si applicano, come si concentra il traffico su intervalli brevi, come viene gestita la ricezione e cosa misura ciascun contatore.
Stessa Francoforte, percorsi di rete diversi
La sorgente del flusso e il tuo server applicativo possono trovarsi entrambi a Francoforte, pur occupando data center distinti. In una configurazione di questo tipo, il traffico può uscire da una struttura, attraversare una rete esterna ed entrare nell’altra. La stessa etichetta geografica non implica la condivisione della struttura, dell’operatore di rete o dell’insieme di dispositivi intermedi.
Quando i flussi o i servizi RPC di ERPC e un server VPS o Bare Metal di ERPC si trovano nello stesso sito, i server che erogano i servizi e il server applicativo occupano rack vicini e la comunicazione tra loro rimane sulla rete interna. È questa l’idea alla base di Zero-Distance Communication di ERPC: progettare insieme il posizionamento fisico e il percorso fino all’applicazione ricevente, andando oltre la scelta della stessa città.
Evitare una deviazione su una rete esterna tra i servizi ERPC e il server applicativo accorcia il percorso e riduce, su quel tratto, l’esposizione alla congestione e ai cambiamenti di instradamento delle reti esterne. Un percorso breve, insieme alle risorse necessarie per la ricezione e l’elaborazione, offre una base per sfruttare un flusso veloce. Verifica il risultato sia all’arrivo dei pacchetti sia durante l’elaborazione nell’applicazione.
Le condizioni di rete influenzano ogni tipo di comunicazione
I frammenti mancanti rendono visibile il problema con gli Shreds, ma la qualità della stessa infrastruttura influenza più in generale la ricezione dei dati, le richieste API e l’invio delle transazioni. Il protocollo cambia i sintomi osservati dall’applicazione e i punti che vale la pena misurare.
| Comunicazione | Dove si manifestano gli effetti della rete | Cosa controllare nell’applicazione |
|---|---|---|
| Shreds / UDP | Perdita e ritardo dei pacchetti, e arrivo dei frammenti necessari alla ricostruzione | Shreds validi e tempo necessario per poter ricostruire i dati |
| Geyser Yellowstone gRPC | Attese dovute alle ritrasmissioni TCP, accumulo di dati nel flusso e ritardi | Tempo necessario per ricevere ed elaborare lo stesso aggiornamento |
| RPC, API e traffico tra servizi | Percorsi di andata e ritorno di richieste e risposte, e attese durante la congestione | Tempo di risposta e sua variazione |
| Invio delle transazioni | Percorso della richiesta fino al nodo ricevente | Tempo dalla richiesta di invio alla risposta del nodo |
La vicinanza fisica e politiche operative adeguate favoriscono tutto questo traffico. Misura il tempo di risposta del nodo ricevente separatamente dal tempo necessario affinché una transazione venga inclusa e finalizzata on-chain.
I Gbps non dicono tutto su PPS e raffiche di pacchetti
La larghezza di banda descrive la quantità di dati che può essere trasportata nel tempo. I PPS descrivono il numero di pacchetti elaborati ogni secondo. Una connessione può avere banda ancora disponibile pur raggiungendo un limite di pacchetti al secondo o una restrizione applicata a UDP. La stessa documentazione dei fornitori cloud tratta i limiti di larghezza di banda e PPS come vincoli distinti.[1]
Gli Shreds non arrivano necessariamente a un ritmo regolare. Una raffica di pacchetti può creare sulle code una pressione che la media nasconde. Se i pacchetti si accumulano più velocemente di quanto un dispositivo di rete o il ricevitore riesca a elaborarli, quelli che superano la capacità della coda possono essere scartati.[2]
Chiedi al tuo fornitore di hosting informazioni sulla ricezione UDP sostenuta, sulle raffiche brevi, sui limiti PPS e sulle regole applicate dalla protezione DDoS. L’obiettivo è stabilire condizioni che consentano di accettare in sicurezza il traffico necessario, invece di disabilitare indiscriminatamente la protezione.
Il corretto funzionamento di gRPC non prova quello della ricezione UDP
gRPC basato su TCP e gli Shreds grezzi trasmessi via UDP utilizzano meccanismi di trasporto diversi. TCP offre ritrasmissione e consegna ordinata, mentre gRPC in streaming dispone di un controllo di flusso che tiene conto della capacità del ricevitore. UDP, di per sé, non ritrasmette i pacchetti mancanti e non fa attendere il mittente finché l’applicazione ricevente non recupera il ritardo.[3]
Di conseguenza, il fatto che gRPC funzioni su un server non dimostra che il percorso UDP o il ricevitore funzionino correttamente. Filtri specifici del protocollo, porte, percorsi di consegna e implementazioni del ricevitore richiedono verifiche separate. Anche i ritardi nell’elaborazione di gRPC possono manifestarsi come tempi di attesa o disconnessioni.
Le transazioni/s su gRPC e i pacchetti/s su UDP misurano unità diverse in fasi di elaborazione differenti. Non possono essere confrontati direttamente per calcolare il volume consegnato o un tasso di perdita.
Dai pacchetti in arrivo ai dati utilizzabili
Con un ricevitore che utilizza un socket UDP standard, i pacchetti in arrivo passano attraverso la scheda di rete (NIC), il kernel e il buffer di ricezione del socket prima di raggiungere l’applicazione. Se l’elaborazione rimane indietro, possono essere scartati dopo aver raggiunto l’host. I contatori di ricezione delle interfacce Linux includono pacchetti scartati nelle fasi successive, quindi il solo aumento di un contatore di ricezione non dimostra la consegna all’applicazione.[4]
Una singola coda di ricezione o un core della CPU può trovarsi sotto carico anche quando l’utilizzo complessivo della CPU è basso. Controlla le code della NIC, l’assegnazione degli interrupt e le prestazioni del singolo core. Nell’applicazione, separa la ricezione dal lavoro a valle quando opportuno, mantenendo le operazioni di parsing onerose e un’attività di logging eccessiva fuori dal ciclo di ricezione. Un buffer di ricezione più grande può assorbire raffiche temporanee; non può risolvere un deficit sostenuto di capacità di elaborazione.[5]
Gli Shreds sono frammenti di dati dei blocchi. La correzione d’errore in avanti (FEC) può recuperare i dati mancanti utilizzando Shreds di dati e di codifica dello stesso gruppo, ma la ricostruzione richiede comunque un numero sufficiente di frammenti. Un maggior numero di pacchetti duplicati non sostituisce i frammenti mancanti.[6]
A seconda dell’implementazione, un ricevitore può ricostruire le entry dai frammenti disponibili prima che l’intero slot sia completo.[9] Oltre al numero totale di pacchetti, misura gli Shreds unici validi, i dati ricostruiti e il tempo necessario affinché l’applicazione riconosca l’evento di cui ha bisogno.
Misura ogni fase nello stesso intervallo temporale
Allinea destinazione, porta e intervallo di misurazione su entrambi i lati. Registrare separatamente le seguenti fasi aiuta a circoscrivere l’indagine successiva.
| Punto di misurazione | Cosa registrare | Cosa consente di stabilire |
|---|---|---|
| Mittente | Registri relativi alla destinazione interessata e definizione del contatore | Quale fase dell’invio è stata osservata |
| Punto di ingresso dell’host ricevente | Cattura del traffico UDP interessato, statistiche della NIC e perdite durante la cattura | Quanto traffico era visibile in quel punto di osservazione |
| Sistema operativo e socket | Errori UDP, perdite nel buffer di ricezione e variazioni delle code | Se la ricezione sta accumulando arretrati all’interno dell’host |
| Ricostruzione degli Shreds | Shreds unici validi, ricostruzioni riuscite, dati mancanti ed errori | Se i pacchetti producono i dati necessari |
| Applicazione | Lavoro di elaborazione in attesa e timestamp di rilevamento dello stesso evento | Se la velocità di arrivo si trasferisce all’applicazione |
Se una cattura mostra pochi pacchetti, controlla prima il filtro, l’interfaccia osservata, le perdite di cattura e i pacchetti scartati dalla NIC. Alcuni contatori del sistema operativo coprono l’intero host o namespace di rete; verificane l’ambito e mettili in relazione con le misurazioni dell’applicazione interessata.[4][5]
Modifica le impostazioni dopo aver identificato la fase soggetta alla limitazione. Aumentare soltanto la dimensione di un buffer o di un anello può spostare il collo di bottiglia o aggiungere tempo di attesa. La configurazione attuale del ricevitore ERPC e le verifiche sono documentate qui:
Scegli la politica operativa oltre al server
La Solana Foundation spiega l’importanza del controllo su NIC, core fisici, driver e rete per i validatori ad alte prestazioni. Questi requisiti per un validatore completo non dovrebbero essere applicati integralmente a ogni ricevitore di Shreds. Un’applicazione ricevente ha bisogno di una configurazione adatta al proprio flusso e al proprio carico di elaborazione.[7]
Ridurre i costi o il consumo energetico è un obiettivo operativo ragionevole. Le applicazioni HFT e in tempo reale hanno inoltre bisogno di una risposta rapida della CPU, di capacità di elaborazione sostenuta e di brevi attese di rete. L’uscita da uno stato di risparmio energetico può comportare un compromesso in termini di latenza.[8]
Oltre ai modelli di CPU e al numero di core, controlla come vengono condivise le risorse, come viene gestito il carico sostenuto, le condizioni per il traffico UDP e il percorso di rete effettivo.
ERPC considera insieme il flusso e l’ambiente di ricezione
ERPC lavora sulla selezione di data center vicini all’infrastruttura Solana, sui percorsi di rete, sull’hardware e sulle impostazioni operative, offrendo VPS e Bare Metal insieme a Shreds e gRPC. Puoi scegliere un VPS in base al tuo carico di elaborazione e confrontare Bare Metal quando desideri risorse fisiche esclusive.
La conoscenza della configurazione e del funzionamento degli ambienti che forniamo supporta anche la risoluzione dei problemi tecnici. Possiamo confrontare i registri lato mittente con le misurazioni del ricevitore e individuare verifiche concrete per la rete, il sistema operativo o l’applicazione. Nella richiesta descritta qui, abbiamo verificato le misurazioni lato mittente e richiesto ulteriori misurazioni al ricevitore.
Valutare insieme il flusso, il posizionamento del ricevitore e l’implementazione dell’applicazione rende più semplice individuare ciò che manca tra il servizio scelto e i dati di cui hai bisogno.
Confronta il tuo ambiente attuale con la fatturazione oraria
Se hai dubbi sul tuo ambiente di ricezione, prova un VPS o un server Bare Metal di ERPC con fatturazione oraria e confronta usando lo stesso flusso e la stessa applicazione. Consulta la dashboard per conoscere prezzi attuali, disponibilità e condizioni di ordinazione nella regione che preferisci.
Inizia con una configurazione disponibile e registra i conteggi di ricezione, i dati ricostruiti, il lavoro di elaborazione in attesa e i timestamp di rilevamento degli stessi eventi. Quando confronti timestamp tra host, verifica anche l’accuratezza della sincronizzazione degli orologi. Ripeti il test in momenti diversi e confronta i punti del percorso in cui i risultati differiscono. Usa queste misurazioni per scegliere un server e un data center adatti alla tua applicazione.
- VPS: https://erpc.global/it/vps/
- Bare Metal: https://erpc.global/it/baremetal/
- Dashboard: https://dashboard.erpc.global/it/
Articoli correlati
- Solana Stream SDK v4.0.0: https://erpc.global/it/news/2026/11/07/erpc-solana-stream-sdk-v4-20261107/
- [9] Shreds UDP Forwarding Premium: https://erpc.global/it/news/2026/11/03/erpc-shreds-udp-forwarding-premium-20261103/
- Discord ufficiale di Validators DAO: https://discord.gg/C7ZQSrCkYR
Riferimenti tecnici
- [1] Limiti di larghezza di banda e PPS di AWS EC2: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html
- [2] Linee guida IETF sull’uso di UDP, raffiche: https://www.rfc-editor.org/rfc/rfc8085.html#section-3.1.6
- [3] UDP in Linux: https://man7.org/linux/man-pages/man7/udp.7.html
- [3] TCP in Linux: https://man7.org/linux/man-pages/man7/tcp.7.html
- [3] Controllo di flusso di gRPC: https://grpc.io/docs/guides/flow-control/
- [4] Statistiche delle interfacce Linux: https://docs.kernel.org/networking/statistics.html
- [4] Comportamento e perdite di cattura di libpcap: https://github.com/the-tcpdump-group/libpcap/blob/master/doc/README.linux
- [5] Scalabilità nello stack di rete Linux: https://docs.kernel.org/networking/scaling.html
- [5] Buffer di ricezione dei socket Linux: https://man7.org/linux/man-pages/man7/socket.7.html
- [5] Red Hat, analisi dei pacchetti UDP scartati: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/network_troubleshooting_and_performance_tuning/tuning-udp-connections
- [6] Anza, propagazione dei blocchi con Turbine: https://docs.anza.xyz/consensus/turbine-block-propagation/
- [7] Solana Foundation, hardware per validatori ad alte prestazioni: https://solana.com/news/high-performance-solana-validators-run-on-bare-metal-hardware
- [8] Gestione dei periodi di inattività della CPU in Linux: https://docs.kernel.org/admin-guide/pm/cpuidle.html
