VPS-Leistung selbst messen: vier Werte, die zählen

„4 vCPU, 8 GB RAM, NVMe“ steht bei jedem Anbieter. Was dahinter steckt, unterscheidet sich um ein Vielfaches, je nach Prozessorgeneration, Überbuchung und Nachbarn auf demselben Blech. Diese vier Messungen zeigen den Unterschied, und sie laufen auf jeder Maschine in einer Viertelstunde.

Was hier bewusst nicht steht

Keine Vergleichstabelle mit Anbieternamen und Punktzahlen. Solche Zahlen altern innerhalb von Wochen, hängen vom Standort und vom Zufall der Nachbarschaft ab und wer sie ohne Methode veröffentlicht, verkauft eine Momentaufnahme als Wahrheit. Hier stehen die Befehle. Die Zahlen erzeugst du selbst, auf der Maschine, um die es geht.

1. Steal Time, der wichtigste Wert zuerst#

Steal Time ist die Zeit, in der dein Prozess rechnen wollte, aber der Hypervisor die CPU jemand anderem gegeben hat. Sie ist der direkteste Hinweis auf einen überbuchten Wirt.

vmstat 1 10
# Spalte "st". Dauerhaft 0–1 ist gut. Über 3 ist ein Problem,
# über 10 ist die Maschine für rechenintensive Dienste unbrauchbar.

Wichtig: einmal messen genügt nicht. Überbuchung zeigt sich abends und am Wochenende, nicht dienstags um zehn.

# Über einen Tag mitschreiben, dann ansehen
( while :; do echo "$(date +%H:%M) $(vmstat 1 2 | tail -1 | awk '{print $16}')"; sleep 300; done ) >> /tmp/steal.log &

2. CPU, einzeln und gesamt#

Spielserver, Datenbanken und PHP hängen an der Einzelkernleistung; Kompression und Bildverarbeitung an der Summe. Beides messen:

apt install sysbench
sysbench cpu --cpu-max-prime=20000 --threads=1 run    # ein Kern
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) run   # alle

Interessant ist nicht der Absolutwert, sondern das Verhältnis: Skaliert die Maschine von einem Faden auf alle annähernd linear? Wenn nicht, teilen sich deine vCPUs physische Kerne, oder die Nachbarn arbeiten gerade.

lscpu | grep -E "Model name|MHz|Thread|Core"

3. Platte, nicht die sequenzielle Zahl#

Anbieter nennen gern Werte für großes, fortlaufendes Lesen. Im Alltag zählt wahlfreier Zugriff mit kleinen Blöcken: Datenbanken, Protokolle, viele kleine Dateien.

apt install fio
fio --name=zufall --ioengine=libaio --direct=1 --rw=randrw --rwmixread=70 \
    --bs=4k --size=2G --numjobs=1 --iodepth=16 --runtime=60 --time_based \
    --group_reporting

Zwei Größen aus der Ausgabe: IOPS und die Latenz im 99. Perzentil. Die zweite ist die ehrlichere, ein Server mit guten Durchschnittswerten und schlechter Ausreißerlatenz fühlt sich träge an, obwohl die Zahlen gut aussehen.

# Zum Vergleich die sequenzielle Zahl, die im Datenblatt steht:
fio --name=seq --ioengine=libaio --direct=1 --rw=read --bs=1M --size=2G --runtime=30 --time_based

Erst prüfen, ob du überhaupt messen darfst

Ein Dauerlauf über Stunden mit voller Plattenlast kann bei manchen Anbietern gegen die Nutzungsbedingungen verstoßen und er belastet die Nachbarn genauso, wie sie dich belasten. Kurze Läufe genügen für den Vergleich, und in die Nutzungsbedingungen zu sehen kostet zwei Minuten.

4. Netz, Durchsatz und Weg#

# Gegenstelle: ein öffentlicher iperf3-Server oder ein zweiter eigener Server
iperf3 -c <gegenstelle> -t 30            # TCP, hin
iperf3 -c <gegenstelle> -t 30 -R         # und zurück

Der Durchsatz ist selten das Problem. Der Weg dorthin schon:

mtr -rwzc 100 <zielregion>

Für Dienste mit Menschen daran, Spielserver, Videokonferenz, Fernzugriff, ist die Laufzeit zu den Nutzern wichtiger als jede Gigabit-Angabe. Details dazu: Lag messen statt raten.

Was die Messung nicht misst#

Verfügbarkeit. Zeigt sich erst über Monate. Dafür brauchst du Monitoring von außen, nicht einen Testlauf.
Support. Die Antwortzeit im Störfall ist im Zweifel mehr wert als 10 % mehr IOPS.
Standort und Rechtslage. Wo die Maschine steht, entscheidet über Laufzeit und über Zuständigkeiten.
Was passiert, wenn du wächst. Kann der Anbieter aufrüsten, ohne Umzug?

Diese vier Punkte gehören mit in die Auswahl, VPS auswählen: die Kriterien, die im Datenblatt fehlen.

Vergleichen, ohne sich zu täuschen#

Gleiche Befehle, gleiche Parameter auf beiden Maschinen. Ein anderer --bs-Wert macht jeden Vergleich wertlos.
Mehrfach messen, verteilt über Tag und Woche.
Datum, Uhrzeit, Prozessormodell und Standort mitschreiben. Ohne diese vier Angaben ist eine Zahl später wertlos.
Stundenweise abrechnen, wenn möglich: Ein Testtag kostet dann weniger als ein Mittagessen.

Häufige Fragen#

Reicht nicht ein fertiges Benchmark-Skript?#

Die verbreiteten Skripte messen sinnvolle Dinge und sind bequem. Nur: Sie laufen als fremdes Skript mit deinen Rechten, und ihre Punktzahlen sind zwischen Versionen nicht vergleichbar. Wer die vier Befehle oben kennt, braucht sie nicht.

Was ist ein guter Steal-Time-Wert?#

Nahe null. Alles ab etwa 3 % dauerhaft heißt: Du bezahlst Rechenzeit, die du nicht bekommst.

Warum ist meine Maschine abends langsamer?#

Weil die Nachbarn dann arbeiten. Genau das macht die eine Messung wertlos und die Aufzeichnung über einen Tag wertvoll.

Sind dedizierte Kerne den Aufpreis wert?#

Für Datenbanken und Spielserver in der Regel ja, für eine Website mit wenig Verkehr selten. Die Messung oben beantwortet die Frage für deinen Fall.

Kann ich RAM-Geschwindigkeit messen?#

Ja, etwa mit sysbench memory. Relevant wird das vor allem, wenn du ein Sprachmodell auf CPU betreibst, dort ist die Speicherbandbreite der Engpass.

Kurz gesagt#

Steal Time zuerst. Ist sie hoch, erübrigt sich der Rest.
CPU einzeln und gesamt messen; das Verhältnis verrät die Überbuchung.
Bei der Platte zählt wahlfreier Zugriff und die Ausreißerlatenz, nicht die Datenblattzahl.
Netz: Durchsatz messen, aber über den Weg entscheiden.
Mehrfach messen, alles mitschreiben. Eine Zahl ohne Datum ist kein Argument.