Solana VPS und Bare Metal: CPU, UDP, Netzwerk im Vergleich | ERPC

Warum der Server für Solana genauso wichtig ist wie der Stream

Ein schneller Solana-Stream bedeutet nicht, dass die Anwendung die Daten ebenso schnell verarbeiten kann. CPU-Auslastung und beworbene 1 Gbit/s reichen als Erklärung nicht aus. Entscheidend ist der gesamte Weg von der Datenquelle bis zur nutzbaren Information. Wir erläutern anonymisierte Untersuchungen und unabhängige Benchmarks, ohne einen bestimmten Hoster für ein ungeklärtes Problem verantwortlich zu machen.

Schnelle Blockchain, große und teilweise stoßartige Datenmengen

Shreds und Yellowstone Geyser gRPC liefern kontinuierlich Daten, oft mit kurzen Lastspitzen. Bandbreite, Pakete pro Sekunde (PPS), RTT, Jitter, Paketverlust und Anwendungsverarbeitung sind getrennte Größen. Vier MB/s über 30 Tage ergeben rund 10,4 TB, entsprechen im Mittel aber nur 32 Mbit/s. Daraus folgt weder, dass 1 Gbit/s unzureichend ist, noch dass eine schnellere Portangabe das Problem löst.

Der Stream läuft, trotzdem bleiben Shreds unvollständig

In einem anonymisierten Fall zeigten Messungen am Sender rund 3.400–3.900 UDP-Pakete/s. Zu einem anderen Zeitpunkt wurden am Empfänger ungefähr 13 Pakete/s gemeldet. Die empfangenen Shreds waren gültig, reichten jedoch nicht zur Rekonstruktion. gRPC funktionierte auf demselben Host. Die Werte stammen aus unterschiedlichen Zeitfenstern und Messpunkten: Daraus lassen sich weder eine Verlustquote noch eine Ursache ableiten. Einige Tausend PPS sind nicht generell zu viel für gewöhnliche Server.

Zuerst bestimmen, wo Pakete beobachtet werden

UDP kann durch DDoS-Schutz, Netzwerkrichtlinien oder den Virtualisierungshost eingeschränkt werden. Nach dem NIC können Kernel, Socket-Puffer und Anwendung weitere Pakete verlieren. Zuerst den Eingang mit tcpdump erfassen, danach NIC-Zähler, UDP-Fehler und Empfängerschleife prüfen. XDP kann bereits vor tcpdump verwerfen. Sender und Empfänger möglichst im selben Zeitfenster untersuchen und keine Schuldzuweisung aus einer einzelnen Messung ableiten.

Geografisch nah bedeutet nicht unbedingt einen kurzen Netzwerkpfad

Zwei Systeme in Frankfurt können über verschiedene Rechenzentren und Transitnetze kommunizieren. Von einem externen Host wurden zu zwei eng benachbarten Amsterdam-Endpunkten etwa 11 und 23 ms RTT gemessen, obwohl die Endpunkte untereinander rund 0,1 ms auseinanderlagen. Eine weitere Beobachtung ergab zeitweise 5–8 % Verlust und etwa 5 ms Zusatzlatenz im vorgeschalteten Netz. Diese Werte beschreiben einzelne Pfade, nicht alle Provider.

Ausführung nahe an die Datenquelle bringen

RPC-Anbieter und Serververmieter stellen normalerweise unterschiedliche Teile bereit. ERPC entwickelt Shreds, Geyser gRPC, RPC sowie VPS und Bare Metal zusammen. An unterstützten Standorten können Datenquelle und Anwendung über kurze lokale Strecken kommunizieren, ohne unnötige externe Umwege. Zero-Distance Communication bedeutet nicht null physikalische Distanz oder garantierte Latenz. Entscheidend bleibt die tatsächlich gemessene Route.

Was wirklich an der Anwendung ankommt

Bei vergleichbarer Geyser-gRPC-Subscription zu einem Amsterdam-Endpunkt meldete eine externe Umgebung 3,7–4,2 MiB/s und zunehmenden Lag. Ein unabhängiger ERPC-VPS-Test aus Frankfurt mit einem CPU-Kern erreichte im Mittel 9,396 MiB/s und rund 1.910 Transaktionen/s über 60 Sekunden ohne zunehmenden Lag. Auf dem problematischen TCP-Pfad wurden Retransmits beobachtet. Hosts und Client-Implementierungen waren unterschiedlich: kein kontrollierter A/B-Test, keine garantierte ERPC-Beschleunigung. In einem gesonderten HTTP/2-Test ergab ein 16-KiB-Empfangsfenster etwa 2,7 MB/s, ein größeres bis zu 7,1 MB/s.

Der CPU-Name verrät nicht alle Limits

Gleiche CPU-Generation und vCPU-Zahl bedeuten nicht gleiche Boost-, Strom-, Kühlungs- oder Scheduling-Politik. AMD Core Performance Boost und Intel Turbo Boost können im BIOS oder Host deaktiviert sein. Auch aktivierter Boost garantiert bei Dauerlast keine Höchstfrequenz. Die VM sieht möglicherweise die Host-Einstellungen nicht. Deshalb die nachhaltige Rechenleistung unter der konkreten Last messen.

Vier vCPUs, 1,93-fache Leistung im Benchmark

Im veröffentlichten ERPC-Vergleich von AMD-Turin-Systemen mit vier vCPUs und Ubuntu 24.04 in Amsterdam wurden 7.850 gegenüber 4.062 sysbench-CPU-Events/s gemessen, also rund 1,93×. Weitere veröffentlichte Werte nennen etwa 3,2× Speicherbandbreite und 16,6× 4K-Random-Read-IOPS. Das sind Ergebnisse eines bestimmten Tests, nicht die Wirkung allein des CPU-Boosts und keine Leistungszusage für jede Anwendung.

Die Wirtschaftlichkeit von Rechenzentren prägt die Leistung

Strom, Kühlung, Racks, Switches, Netzkapazität und Betrieb kosten Geld. Geteilte Ressourcen und Stromsparregeln sind für typische Workloads wirtschaftlich sinnvoll. Solana-Streams und latenzkritische Anwendungen beanspruchen jedoch CPU-Takt, PPS und Uplinks teils dauerhaft. Shared Bandwidth, DDoS-Regeln und Traffic-Shaping sind kein Beweis für einen schlechten Anbieter. Entscheidend ist, ob die Richtlinien zur eigenen Anwendung passen.

Auch die Cloud-Datenübertragung hat einen Preis

Kontinuierliche Streams erzeugen über Wochen große Datenmengen. Während eingehender Internetverkehr häufig kostenlos ist, können ausgehende Daten, Zonenwechsel und Dienste untereinander kostenpflichtig sein. Bei geeigneten ERPC-Produkten wird interner Plattformverkehr getrennt von externen Transferkontingenten behandelt. Aktuelle Tarifbedingungen und Regionen prüfen. Die Gesamtkosten der Datenstrecke sind wichtiger als nur der VM-Preis.

Die passende Konfiguration für den Workload wählen

Leichte RPC-Arbeit kann auf einem EPYC VPS laufen. Kontinuierliche gRPC-Analyse verlangt CPU- und Speicherreserven, Shreds-UDP-Anwendungen benötigen eine passende UDP-Policy, PPS-Kapazität, kurze Wege und schnelle Erkennung. Bare Metal bietet exklusive physische Ressourcen, ist jedoch nicht bei jeder Anwendung automatisch schneller. Manchmal sind zwei VPS sinnvoll. Vergleichen Sie mit identischen Filtern und Zeitfenstern gültige Shreds, Rekonstruktion, Lag, Retransmits und p95/p99-Verzögerung.

Vor dem langfristigen Vertrag messen

Auf Linux helfen kurze, lesende Tests mit tcpdump, nstat, ip -s link, ethtool -S, ss -tin und lscpu. Die passenden Interfaces und Quelladressen festlegen und Zählerdifferenzen vergleichen. lscpu allein beweist keine Host-Boost-Policy. ERPC bietet für geeignete Konfigurationen stundenweise VPS- und Bare-Metal-Nutzung je nach Bestand. Entscheidend ist, dass die benötigten Daten rechtzeitig nutzbar werden.

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