VPS ou Bare Metal Solana : performances CPU, UDP et réseau

Pourquoi le serveur compte autant que le flux Solana

Un flux Solana rapide ne garantit pas que les données arrivent à temps dans l'application. Un CPU peu chargé et un port annoncé à 1 Gbit/s ne suffisent pas à expliquer une réception incomplète. Il faut examiner tout le parcours, de la source à l'application. Ce guide s'appuie sur des observations anonymisées, des tests indépendants et des mesures publiées, sans désigner un hébergeur comme responsable d'un incident non résolu.

Un débit élevé, mais aussi des paquets et des rafales

Shreds et Yellowstone Geyser gRPC transmettent des données en continu, parfois par rafales. Bande passante, PPS, RTT, gigue, pertes de paquets et temps de traitement sont des indicateurs distincts. Un flux hypothétique de 4 Mo/s pendant 30 jours représente 10,4 To, mais seulement 32 Mbit/s en moyenne. Cela ne prouve pas qu'un port à 1 Gbit/s soit insuffisant. Les limites UDP et PPS, les liens partagés et la capacité de réception restent à vérifier.

Le flux fonctionne, mais les fragments manquent

Dans une enquête anonymisée, la source comptait environ 3 400 à 3 900 paquets UDP/s et un environnement de réception rapportait environ 13 paquets/s à un autre moment. Les Shreds reçus étaient valides, mais insuffisants pour reconstruire les données. gRPC fonctionnait sur le même hôte. Ces mesures ne sont ni synchronisées ni réalisées au même endroit : elles ne prouvent aucun taux de perte ni aucune cause. Quelques milliers de PPS ne dépassent pas intrinsèquement les capacités d'un serveur standard.

Localiser l'observation avant de modifier la machine

Une politique réseau, la protection DDoS ou l'hyperviseur peut limiter UDP avant le serveur invité. Après la carte réseau, le noyau, les buffers de socket et l'application peuvent perdre des paquets. Capturer d'abord le trafic sur l'interface avec tcpdump, puis vérifier les compteurs NIC et UDP et les files d'attente. XDP peut éliminer des paquets avant tcpdump. Comparer les mêmes destinations et fenêtres temporelles avant toute conclusion.

Proches sur la carte, éloignés sur le réseau

Deux serveurs situés à Francfort peuvent passer par des installations et des opérateurs différents, voire un transit externe. Une mesure vers deux endpoints proches à Amsterdam indiquait environ 11 ms et 23 ms de RTT depuis le même hôte externe, bien que ces endpoints soient distants d'environ 0,1 ms entre eux. Une autre période a montré 5 à 8 % de pertes et 5 ms de latence supplémentaire sur le réseau en amont. Ces résultats restent propres aux chemins mesurés.

Exécuter au plus près des sources de données

Habituellement, le fournisseur RPC et l'hébergeur de calcul sont distincts. ERPC conçoit Shreds, Geyser gRPC, RPC, VPS et Bare Metal de façon coordonnée. Dans les sites compatibles, les serveurs de données et d'application utilisent un réseau local et des racks proches. Zero-Distance Communication ne signifie pas une latence littéralement nulle ni un résultat garanti. Le trajet réel doit toujours être mesuré.

Comparer les données réellement reçues

Pour une souscription Geyser gRPC comparable vers Amsterdam, un environnement externe recevait 3,7 à 4,2 MiB/s avec un retard croissant. Un test indépendant depuis un VPS ERPC à Francfort, limité à un cœur CPU, a atteint 9,396 MiB/s et environ 1 910 transactions/s pendant 60 secondes sans retard accumulé. Des retransmissions TCP étaient visibles sur le chemin problématique. Les hôtes et clients étant différents, ce n'est pas un test A/B strict. Un autre test HTTP/2 donnait 2,7 Mo/s avec une fenêtre de 16 KiB et jusqu'à 7,1 Mo/s avec une fenêtre plus grande.

Le modèle du CPU ne révèle pas toutes ses limites

Deux VM dotées de la même génération CPU et du même nombre de vCPU peuvent avoir des politiques de boost, d'alimentation, de refroidissement et de partage distinctes. Core Performance Boost et Turbo Boost peuvent être désactivés par le BIOS ou l'hôte. Lorsqu'ils sont activés, la fréquence maximale n'est pas garantie durablement. Le système invité ne voit pas toujours cette configuration. Mesurer la performance soutenue de l'application.

Quatre vCPU : 1,93× dans une mesure publiée

Dans le benchmark ERPC de VM AMD Turin à quatre vCPU sous Ubuntu 24.04 à Amsterdam, sysbench CPU a produit 7 850 événements/s contre 4 062 pour une VM cloud de comparaison, soit environ 1,93×. La publication indique également environ 3,2× en bande passante mémoire et 16,6× en IOPS de lecture aléatoire 4K. Ces écarts ne sont pas universels et ne prouvent pas que le seul boost CPU en est la cause.

L'économie des centres de données façonne les choix techniques

Électricité, refroidissement, liaisons, commutateurs et exploitation ont un coût. Mutualiser les ressources est rationnel pour les usages ordinaires. Les flux Solana et applications à faible latence peuvent au contraire solliciter durablement les cœurs, le PPS et les liens. Bande passante partagée, limitation par flux, règles DDoS ou économies d'énergie peuvent être adaptées à un marché, mais pas à une charge précise. Il faut évaluer les politiques sans dénigrer les fournisseurs.

Le coût des transferts cloud compte aussi

Un flux continu peut représenter de nombreux téraoctets sur un mois. Le trafic Internet entrant est souvent gratuit, tandis que les transferts sortants, inter-zones et entre services peuvent être facturés. Les produits ERPC éligibles distinguent le trafic local à la plateforme des quotas externes ; vérifier les conditions en vigueur. Comparer le coût du parcours complet, pas uniquement le loyer de la VM.

Adapter VPS ou Bare Metal à la charge réelle

Un EPYC VPS peut suffire à un RPC léger ; une analyse gRPC soutenue nécessite des réserves CPU et mémoire. Les applications UDP sensibles à la latence doivent tester l'admission de paquets, le PPS, les rafales et le temps de détection. Bare Metal donne des ressources physiques exclusives, sans être automatiquement plus rapide pour tout usage. Plusieurs VPS peuvent aussi être pertinents. Comparer les mêmes filtres et périodes, les Shreds valides, la reconstruction, le lag, les retransmissions et les latences p95/p99.

Mesurer avant de s'engager

Sous Linux, tcpdump, nstat, ip -s link, ethtool -S, ss -tin et lscpu fournissent des premières observations sans modifier la configuration. Adapter interface et adresse source ; comparer les compteurs sur une période cohérente. lscpu ne révèle pas à lui seul la politique de boost de l'hyperviseur. ERPC propose un accès horaire aux VPS et Bare Metal éligibles, selon les stocks. Le bon serveur est celui qui fournit à temps les données réellement utilisables.

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