Was messen wir?

Wir benchmarken die vier Dinge, die im Selfhosting-Alltag zählen: CPU, Arbeitsspeicher, NVMe-Disk und Netzwerk – jeweils mit etablierten Open-Source-Tools (sysbench, fio, 7z, openssl, curl). Alle Zahlen unten stammen aus einem echten VPS 1000 G12 unter Debian 13. Das Testgerät: AMD EPYC-Genoa, 4 vCore, 8 GB RAM, 256 GB NVMe.

Die wichtigsten Werte auf einen Blick:

Kurzeinordnung: Für einen Einstiegs-VPS sind das durchweg starke Werte – vor allem die NVMe-Disk und das Netzwerk spielen weit über dem, was man vom günstigsten Tarif erwartet. Wichtig ist aber der Kontext: Ein VPS teilt sich die physische CPU mit anderen Kund:innen (geteilte vCores). Deine Werte können je nach Auslastung der Nachbarn abweichen – wie du das erkennst, steht in „Wenn es nicht funktioniert".

Voraussetzungen

• Ein netcup-Server, z. B. dein erster VPS, mit SSH-Zugang.

• Die Benchmark-Tools. Alle sind in den Debian-Paketquellen:

  Terminal

  sudo apt update
  sudo apt install -y sysbench fio p7zip-full

• Etwas freien Speicherplatz (die Disk-Tests schreiben ein paar GB temporär) und idealerweise keine produktive Last während der Messung.

Schritt für Schritt

Schritt 1: Den Server einordnen

Bevor du misst, schau dir an, womit du es zu tun hast:

grep -m1 "model name" /proc/cpuinfo && nproc && free -h

model name : AMD EPYC-Genoa Processor
4
               total        used        free      shared  buff/cache   available
Mem:           7.8Gi       689Mi       3.0Gi       656Ki       4.3Gi       7.1Gi

Vier vCores auf einer AMD EPYC-Genoa (netcups aktuelle G12-Generation) und 8 GB RAM. Wirf auch einen Blick auf die Steal Time – der Prozentsatz, den die CPU „wartet", weil ein Nachbar auf demselben Host gerade rechnet:

vmstat 1 3

In der Spalte st (ganz rechts) sollte möglichst 0 stehen. Bei uns war sie über den ganzen Test 0 – kein spürbarer Nachbar-Einfluss. Hohe, dauerhafte Steal-Werte wären das Zeichen eines überbuchten Hosts.

Schritt 2: CPU

sysbench rechnet Primzahlen – einmal auf einem Kern, einmal auf allen vieren:

sysbench cpu --cpu-max-prime=20000 --threads=1 run
sysbench cpu --cpu-max-prime=20000 --threads=4 run

1 Thread:   events per second:  1494.66
4 Threads:  events per second:  5973.69

Zwei Dinge sind hier bemerkenswert: die solide Single-Thread-Leistung (Genoa-Kerne sind schnell) und die fast perfekte Skalierung – 4 Threads liefern das 3,996-fache eines einzelnen. Das heißt: Zum Messzeitpunkt standen die vier vCores voll zur Verfügung, ohne dass sich Nachbarn Rechenzeit abgezwackt haben.

Ein zweiter, praxisnaher CPU-Test ist der eingebaute 7-Zip-Benchmark (Kompression, nutzt alle Kerne):

7z b

Tot:  ...  27425  (MIPS gesamt)

7z b misst Kompression und Dekompression getrennt (jeweils eine eigene Zeile) und fasst beide in der Tot:-Zeile zu einem Gesamt-Rating zusammen – das sind die rund 27.400 MIPS. Ein guter Richtwert, um den VPS mit anderen 7-Zip-Ergebnissen im Netz zu vergleichen. Und weil Verschlüsselung überall mitläuft (HTTPS, Backups, VPN), noch die AES-Leistung mit Hardware-Beschleunigung (AES-NI):

openssl speed -evp aes-256-gcm

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
AES-256-GCM      89283.37k   343370.05k  1270428.16k  3164995.93k  7671136.75k  8464845.66k

openssl speed misst standardmäßig single-threaded – die Zahl gilt also für einen Kern. Für den Durchsatz über alle Kerne hängst du -multi $(nproc) an. In unserem Lauf lag ein einzelner Kern bei den 8-KB-Blöcken bei rund 7,7 GB/s (7.671.136 k). TLS ist auf diesem Prozessor damit ohnehin nie der Flaschenhals.

Schritt 3: Arbeitsspeicher

sysbench schreibt einen großen Block wiederholt durch den RAM und misst den Durchsatz:

sysbench memory --memory-block-size=1M --memory-total-size=30G --threads=4 run

30720.00 MiB transferred (28727.21 MiB/sec)

Rund 30 GB/s – reichlich für Datenbanken, Caches (Redis/Valkey) und alles, was viele kleine Objekte im Speicher hält. RAM ist bei diesem Tarif erfahrungsgemäß eher über die Menge (8 GB) als über den Durchsatz limitiert.

Schritt 4: NVMe-Disk

Hier trennt sich Spreu von Weizen – die Disk ist bei den meisten selbstgehosteten Apps der eigentliche Flaschenhals. fio misst realistisch, wenn du mit --direct=1 den Seiten-Cache umgehst (sonst misst du den RAM, nicht die Platte). Zuerst die für Datenbanken entscheidenden 4K-Random-IOPS:

# Lesen (4K random read)
fio --name=rr --ioengine=libaio --direct=1 --rw=randread --bs=4k \
  --numjobs=4 --iodepth=32 --size=512M --runtime=20 --time_based --group_reporting

# Schreiben (4K random write) – gleicher Befehl, nur --rw=randwrite
fio --name=rw --ioengine=libaio --direct=1 --rw=randwrite --bs=4k \
  --numjobs=4 --iodepth=32 --size=512M --runtime=20 --time_based --group_reporting

read:  IOPS=101k, BW=394MiB/s
write: IOPS=67.0k, BW=262MiB/s

101.000 Lese- und 67.000 Schreib-IOPS bei 4K – das ist echtes NVMe-Niveau und der Grund, warum sich Nextcloud, Datenbanken oder Paperless auf diesem VPS spürbar flüssig anfühlen. Und der sequenzielle Durchsatz (große Dateien, Backups, Video):

# Lesen (sequenziell)
fio --name=sr --ioengine=libaio --direct=1 --rw=read --bs=1M \
  --numjobs=1 --iodepth=16 --size=2G --runtime=15 --time_based

# Schreiben (sequenziell) – gleicher Befehl, nur --rw=write
fio --name=sw --ioengine=libaio --direct=1 --rw=write --bs=1M \
  --numjobs=1 --iodepth=16 --size=2G --runtime=15 --time_based

READ:  bw=4123MiB/s (4,3 GB/s)
WRITE: bw=2937MiB/s (3,1 GB/s)

4,3 GB/s lesend, 3,1 GB/s schreibend. Ein restic-Backup oder ein großer docker pull ist damit in Sekunden durch.

Schritt 5: Netzwerk

Für den Durchsatz lädst du eine große Testdatei von einem gut angebundenen Server. Wir nehmen den Hetzner-Speedtest in Falkenstein (Deutschland):

curl -o /dev/null -w "%{speed_download} B/s in %{time_total}s\n" \
  https://fsn1-speed.hetzner.com/1GB.bin

246095181 B/s in 4.36s

~246 MB/s, also rund 2 Gbit/s – 1 GB in gut vier Sekunden. Ein Download aus den USA (Ashburn) lag distanzbedingt bei ~36 MB/s; innerhalb Europas ist die Anbindung exzellent. Zum Schluss die Latenz:

ping -c 5 1.1.1.1

rtt min/avg/max/mdev = 12.314/12.337/12.365/0.019 ms

~12 ms zu 1.1.1.1 (Cloudflares Anycast-Resolver, also ein naher Netzknoten – kein rein deutsches Zi), sehr konstant (die Abweichung liegt im Hundertstel-Bereich). IPv6 ist aktiv und funktioniert; ein Ping über IPv6 lag bei ~26 ms.

Wenn es nicht funktioniert

Performance im Blick behalten

• Für wen reicht der VPS 1000 G12? Für praktisch alle Einzeldienste dieser Seite – SSH, Traefik, Vaultwarden, Uptime Kuma, ein kleines Nextcloud. Eng wird es weniger bei CPU oder Disk als beim RAM: Sobald mehrere schwere Apps (Nextcloud
  • Immich + Datenbanken) parallel laufen, ist ein Upgrade zum VPS 2000 (16 GB) der sinnvollste nächste Schritt.
• Steal Time dauerhaft beobachten. Ein einmaliger Benchmark ist eine Momentaufnahme. Wer die Leistung langfristig im Blick behalten will, nimmt CPU-Steal, I/O und Netzwerk in ein Grafana-Dashboard auf – dort siehst du schleichende Verschlechterung, bevor sie weh tut.
• Nach Änderungen neu messen. Ein Server-Umzug, ein Produktwechsel oder eine neue netcup-Generation verändert die Werte. Bewahre deine Benchmark-Ausgaben auf (ein einfaches Textfile im Backup genügt), dann hast du eine Vergleichsbasis.
• Ehrlich bleiben: Benchmark-Zahlen altern und schwanken. Sie sind eine Orientierung, kein Versprechen – die geteilten vCores bedeuten, dass die reale Leistung immer auch von den Nachbarn auf dem Host abhängt. Für den Einstiegspreis liefert der VPS 1000 G12 aber eine bemerkenswert runde Vorstellung.