// <a href="https://hosting-fixers.de/category/pagespeed/" rel="category tag">Pagespeed</a>
WordPress VPS Benchmark 2026: 4 schnelle CPU-Kerne gegen 8 vCPU
Ein VPS mit acht virtuellen CPU-Kernen klingt nach mehr Leistung als einer mit vier. Für WordPress stimmt das nicht zwingend. Entscheidend ist, wie schnell ein einzelner CPU-Kern arbeitet – und wie niedrig die Storage-Latenzen sind. Dieser Artikel dokumentiert einen konkreten Benchmark-Vergleich zwischen einem netcup RS 1000 G12 (4 dedizierte AMD-EPYC-Kerne, NVMe) und einem älteren Contabo VPS L (8 vCPU, Intel Broadwell, SSD). Alle Messwerte stammen aus eigenen Tests mit sysbench und YABS/FIO.
Ausgangssituation: Warum ein neuer Server gesucht wurde
Der Anlass war pragmatisch: Für drei dynamische WordPress-Websites mit hohem Performance-Anspruch wurde eine neue Serverplattform gesucht. Geplanter Stack: Plesk, nginx, PHP-FPM, MariaDB, Redis Object Cache, OPcache, Cloudflare und ein Security-Layer. Der bisherige Contabo VPS L ist ein älteres Bestandssystem und bleibt zunächst parallel in Betrieb. Ziel des Benchmarks: prüfen, ob der netcup RS 1000 G12 das passendere Performance-Profil für diesen Einsatzzweck mitbringt.
Die beiden Testsysteme
Vorab ein wichtiger Hinweis zur Fairness: Der Contabo-Server ist ein älterer Bestandsserver (VPS L), kein heute neu bestellter Tarif. Die gemessenen Werte spiegeln den konkreten Stand dieses Systems wider – nicht zwingend aktuelle Contabo-Hardware.
| Merkmal | netcup RS 1000 G12 | Contabo VPS L (alt) |
|---|---|---|
| CPU-Modell | AMD EPYC 9645 | Intel Broadwell |
| CPU-Zuweisung | 4 dedizierte Kerne | 8 vCPU |
| CPU-Takt | 2,30 GHz Basis | ca. 2,2 GHz |
| RAM | 8 GB (7,76 GB sichtbar) | ca. 29,4 GiB |
| Storage | 256 GB NVMe | ca. 825 GB SSD |
| Virtualisierung | KVM | KVM |
| Betriebssystem | Debian 13 (Trixie), Kernel 6.12 | – |
| Netzwerk | bis 2,5 Gbit/s | ca. 600 Mbit/s (gemessen) |
| Sysbench 1 Thread | 1.659 events/s | 277 events/s |
| Sysbench 4 Threads | 6.450 events/s | 1.089 events/s |
| 4K IOPS kombiniert | ~100.979 | ~31.855 |
| 64K I/O kombiniert | ~3.666 MB/s | ~813 MB/s |
| 1M I/O kombiniert | ~4.529 MB/s | ~1.133 MB/s |
| Netzwerk Europa | ~2,3–2,7 Gbit/s | ~600 Mbit/s |
Die vollständigen YABS-Ergebnisse sind öffentlich nachvollziehbar: netcup RS 1000 G12 · Contabo VPS L (alt).
CPU-Test: Warum 4 Kerne 8 vCPU schlagen können
Testbefehl für beide Systeme identisch:
sysbench cpu --threads=1 --cpu-max-prime=20000 --time=60 runSingle-Core-Performance
Das ist der aussagekräftigste Wert für dynamische WordPress-Requests – ein PHP-FPM-Worker arbeitet einen Request weitgehend sequenziell auf einem einzigen Kern ab:
| Messwert | netcup RS 1000 G12 | Contabo VPS L (alt) |
|---|---|---|
| Events/Sekunde | 1.659,37 | 277,22 |
| Events gesamt (60 s) | 99.565 | 16.635 |
| Latenz Minimum | 0,58 ms | 3,16 ms |
| Latenz Durchschnitt | 0,60 ms | 3,60 ms |
| Latenz Maximum | 2,34 ms | 14,66 ms |
| Latenz P95 | 0,62 ms | 4,49 ms |
| Verhältnis | 5,99× zugunsten netcup | |
Der einzelne EPYC-Core erreichte knapp die sechsfache Eventrate des getesteten Contabo-Kerns. Das bedeutet nicht, dass WordPress generell sechsmal schneller läuft – sysbench misst CPU-Rechenleistung, keinen vollständigen Webstack. Es zeigt aber, wie viel Rechenarbeit ein einzelner Kern pro Zeiteinheit leisten kann, und das ist für PHP-FPM ein sehr relevanter Indikator.
Multi-Core-Skalierung mit 4 Threads
Methodischer Hinweis: Der 4-Thread-Test lief auf dem netcup-Server 60 Sekunden, auf dem Contabo-Server 300 Sekunden. Events/s ist zeitnormiert – die unterschiedliche Laufzeit ist der Transparenz halber erwähnt.
| Messwert | netcup (60 s) | Contabo (300 s) |
|---|---|---|
| Events/Sekunde (4 Threads) | 6.450,17 | 1.088,94 |
| Events gesamt | 387.020 | 326.691 |
| Latenz Durchschnitt | 0,62 ms | 3,67 ms |
| Latenz Maximum | 4,65 ms | 37,52 ms |
| Latenz P95 | 0,64 ms | 4,49 ms |
| Verhältnis | 5,92× zugunsten netcup | |
Die Skalierung von 1 auf 4 Threads ist bei beiden Systemen nahezu identisch effizient:
| netcup | Contabo | |
|---|---|---|
| Theoretisch linear (×4) | 6.637 events/s | 1.109 events/s |
| Gemessen (4 Threads) | 6.450 events/s | 1.089 events/s |
| Skalierungseffizienz | 97,2 % | 98,2 % |
Beide Systeme skalieren über vier Threads nahezu linear. Das Problem des älteren Contabo ist in diesem Test nicht eine schlechte Multi-Core-Skalierung – sondern die erheblich niedrigere Rechenleistung jedes einzelnen virtuellen Kerns.
Was ist wichtiger für WordPress: CPU-Kerne oder Single-Core-Leistung?
Für einen einzelnen dynamischen WordPress-Request ist Single-Core-Leistung entscheidend. PHP-FPM verarbeitet jeden Request weitgehend sequenziell in einem Worker-Prozess – die Arbeit lässt sich nicht auf mehrere Kerne verteilen. Schnellere einzelne Kerne bedeuten kürzere PHP-Ausführungszeiten und damit niedrigeren TTFB. Viele Kerne helfen dagegen bei Parallelität: Wenn viele Besucher gleichzeitig dynamische Seiten aufrufen, bearbeitet PHP-FPM mehrere Workers parallel – hier zahlt sich eine höhere Kernzahl aus. Für wenige Websites mit moderatem gleichzeitigen Traffic ist Single-Core-Leistung in den meisten Fällen der wichtigere Faktor.
Warum WordPress schnelle einzelne CPU-Kerne braucht
Der vereinfachte Request-Pfad eines dynamischen WordPress-Aufrufs:
Browser → CDN/Cloudflare → nginx → PHP-FPM-Worker → WordPress + Plugins + Theme → MariaDB → AntwortEin einzelner PHP-FPM-Worker läuft als einzelner Prozess auf einem CPU-Kern. WordPress-Core, aktive Plugins, Theme-Rendering, Datenbankabfragen und Template-Ausgabe – das passiert sequenziell innerhalb dieses einen Workers. Mehr Kerne bedeuten mehr parallele Workers für mehr gleichzeitige Requests. Aber die Ausführungsgeschwindigkeit eines einzelnen Requests hängt primär von der Single-Core-Leistung ab.
Viele Kerne helfen dennoch konkret bei:
- Vielen gleichzeitigen Besuchern auf dynamischen Seiten (Parallelität)
- Parallelen WP-CLI-Prozessen und WordPress-Cronjobs
- Backup-Prozessen während des laufenden Betriebs
- Gleichzeitiger Bildverarbeitung (EWWW, Imagify)
- Malware-Scans im Hintergrund
- Parallelen Datenbankoperationen
Für wenige WordPress-Websites mit moderatem Traffic ist der entscheidende Engpass meist nicht die Parallelität, sondern die Abarbeitungsgeschwindigkeit eines einzelnen Requests. Dabei helfen neben schnellen CPU-Kernen ein gut dimensionierter PHP-FPM-Pool, OPcache und ein persistenter Object Cache wie Redis.
Wie viele CPU-Kerne braucht ein WordPress-Server?
Eine einzelne WordPress-Website benötigt unter normalen Bedingungen nicht mehr als 2–4 CPU-Kerne, wenn diese modern und schnell sind. Entscheidend ist die Zahl gleichzeitiger dynamischer Requests: Mit OPcache, Page-Cache (Nginx FastCGI) und Object Cache (Redis) trifft PHP-FPM nur einen Bruchteil der Gesamtanfragen. Drei WordPress-Websites laufen auf 4 schnellen Kernen stabiler als auf 8 langsamen, wenn der Traffic nicht außergewöhnlich hoch ist.
NVMe gegen SSD – aber IOPS zählen mehr als das Label
NVMe und SSD sind Labels – die tatsächliche I/O-Leistung hängt vom konkreten System ab. Die YABS/FIO-Messwerte:
4K Random I/O – der wichtigste Wert für Datenbankbetrieb
| Messwert | netcup RS 1000 G12 (NVMe) | Contabo VPS L (SSD) |
|---|---|---|
| 4K Read | ~201,7 MB/s | ~63,6 MB/s |
| 4K Write | ~202,2 MB/s | ~63,8 MB/s |
| 4K kombiniert | ~403,9 MB/s | ~127,4 MB/s |
| 4K Read IOPS | ~50.423 | ~15.910 |
| 4K Write IOPS | ~50.556 | ~15.945 |
| 4K IOPS kombiniert | ~100.979 | ~31.855 |
| Faktor | ≈ 3,2× zugunsten netcup | |
Größere Blockgrößen
| Blockgröße | netcup (kombiniert) | Contabo (kombiniert) | Faktor |
|---|---|---|---|
| 64K | ~3.666 MB/s | ~813 MB/s | ≈ 4,5× |
| 512K | ~3.827 MB/s | ~1.309 MB/s | ≈ 2,9× |
| 1M | ~4.529 MB/s | ~1.133 MB/s | ≈ 4,0× |
In diesen YABS/FIO-Messungen erreichte der netcup-Server je nach Blockgröße ungefähr die 2,9- bis 4,5-fache kombinierte I/O-Leistung des älteren Contabo-Systems.
Wie wichtig sind NVMe und IOPS für WordPress?
WordPress und MariaDB erzeugen überwiegend kleine, zufällige I/O-Vorgänge: Datenbanklesezugriffe auf wp_options, wp_postmeta und wp_posts, Transient-Schreibvorgänge, Cache-Dateien, Logs und Plugin-Operationen. Für diese Workloads sind IOPS (Input/Output Operations Per Second) und I/O-Latenz relevanter als sequenzielle Durchsatzwerte in GB/s. Ein System mit höheren 4K-IOPS reduziert Wartezeiten bei Datenbankzugriffen – direkt messbar im TTFB. Mit Page-Cache und Object Cache (Redis) wird der Storage weniger belastet; trotzdem bleibt schneller Storage ein Vorteil bei Cache-Misses, Updates, Cronjobs und Backup-Operationen.
Netzwerk: 2,5 Gbit/s vs. 600 Mbit/s
| Gegenstelle | netcup Upload | netcup Download | Contabo Upload | Contabo Download |
|---|---|---|---|---|
| Amsterdam | ~2,70 Gbit/s | ~2,36 Gbit/s | ~599 Mbit/s | ~599 Mbit/s |
| London | ~2,70 Gbit/s | ~2,37 Gbit/s | ~597 Mbit/s | ~599 Mbit/s |
| New York | ~2,48 Gbit/s | ~2,04 Gbit/s | ~529 Mbit/s | ~533 Mbit/s |
Für normale WordPress-Seitenaufrufe sind 600 Mbit/s weit mehr als ausreichend. Der Unterschied macht sich bei Server-zu-Server-Migrationen, externen Backups, Synchronisation großer Medienbibliotheken und parallelen Datenströmen bemerkbar.
Fair-Use-Hinweis netcup: Bei mehr als 3 TB Datenverkehr innerhalb von 24 Stunden drosselt netcup temporär auf 300 Mbit/s. Für drei WordPress-Websites ist diese Grenze im Normalbetrieb sehr hoch – 3 TB/24 h entspricht ~278 Mbit/s Dauerlast.
Der große Vorteil des älteren Contabo: RAM und Speicherplatz
| Ressource | netcup RS 1000 G12 | Contabo VPS L (alt) | Vorteil |
|---|---|---|---|
| RAM | 8 GB | ~29,4 GiB | Contabo ≈ 3,8× |
| Storage | 256 GB NVMe | ~825 GB SSD | Contabo ≈ 3,2× |
Für sehr viele Websites, große Datenbanken, speicherintensive Anwendungen oder viele gleichzeitige PHP-FPM-Worker kann mehr RAM der entscheidende Faktor sein. Für den geplanten Einsatz mit drei WordPress-Websites, Redis Object Cache und gut dimensioniertem PHP-FPM-Pool reichen 8 GB RAM – aber das ist eine situationsspezifische Einschätzung.
Was bedeutet das für WordPress-Hosting?
- PHP-FPM: Mit schnelleren Kernen können Workers mit weniger CPU-Zeit pro Request auskommen. Das erlaubt einen konservativeren Pool bei gleicher oder besserer Antwortzeit. Zur PHP-FPM-Dimensionierung gibt es einen separaten Leitfaden.
- MariaDB: Höhere 4K-IOPS bedeuten schnellere Datenbankzugriffe bei Cache-Misses. Besonders relevant für wp_options-Autoload, komplexe JOIN-Abfragen und hohe gleichzeitige Schreiblast.
- Redis Object Cache: Reduziert Datenbankzugriffe erheblich – aber bei Cache-Misses und Cronjobs schlägt die I/O-Leistung durch.
- OPcache: Eliminiert das erneute Kompilieren von PHP-Dateien. Auf schnelleren Kernen ist der OPcache-Warmup nach einem Neustart schneller abgeschlossen.
- Cloudflare und Page-Cache: Entlastet PHP-FPM für anonyme Besucher komplett. Die CPU-Leistung kommt dann primär bei eingeloggten Nutzern, Cronjobs und dynamischen Seitenteilen zum Tragen.
Welche Serverkennzahlen sollte man für WordPress prüfen?
- CPU-Modell und Generation – nicht nur die vCPU-Zahl. EPYC, Xeon Scalable oder Broadwell sind nicht vergleichbar.
- Single-Core-Benchmark – sysbench oder Geekbench Single-Core. Für PHP-FPM der relevanteste CPU-Wert.
- CPU-Steal – bei VPS ein Indikator für Host-Überbuchung. Messbar mit
top(Spalte %st) odervmstat. - 4K Random IOPS – für MariaDB-Workloads wichtiger als sequenzielle MB/s.
- I/O-Latenz – niedrige Latenz bei kleinen Zugriffen reduziert TTFB bei Datenbankoperationen direkt.
- RAM – für PHP-FPM-Worker, MariaDB InnoDB Buffer Pool, Redis und OPcache.
- Netzwerkbandbreite – ab ~100 Mbit/s kein Engpass für normale Websites; relevant bei Backups und Migrationen.
- Konstante Performance – Benchmarks zu verschiedenen Zeiten wiederholen, um Überbuchungseffekte zu erkennen.
Testmethodik und Transparenzhinweise
- Der Contabo VPS L ist ein älterer Bestandsserver – kein aktuell neu bestelltes System.
- Beide Server gehören unterschiedlichen Hardwaregenerationen an (EPYC 9645 vs. Intel Broadwell).
- sysbench und YABS/FIO sind synthetische Benchmarks – kein direkter WordPress-Application-Test wurde durchgeführt.
- Der 4-Thread-sysbench-Test lief auf dem netcup-Server 60 Sekunden, auf dem Contabo-Server 300 Sekunden. Events/s ist zeitnormiert, die unterschiedliche Laufzeit ist der Transparenz halber aufgeführt.
- VPS-Leistung kann je nach Host-Auslastung und Testzeitpunkt variieren.
- Für direkte TTFB- oder Requests-per-Second-Aussagen wäre ein identischer WordPress-Application-Benchmark nötig.
Fazit: Ressourcenprofil statt Kernanzahl entscheidet
Mehr vCPU bedeuten nicht automatisch mehr WordPress-Performance. Im konkreten Test standen 8 ältere virtuelle CPU-Kerne (Intel Broadwell, ca. 2,2 GHz) gegen 4 moderne dedizierte EPYC-Kerne (AMD EPYC 9645, 2,30 GHz Basis). Trotz halbierter Kernanzahl erreichte der netcup RS 1000 G12 in sysbench knapp die sechsfache Single-Thread-Eventrate und ~3,2× höhere kombinierte 4K-IOPS.
Für den geplanten Einsatz – drei dynamische WordPress-Websites, Plesk, nginx, PHP-FPM, MariaDB, Redis, OPcache, Cloudflare – ist der RS 1000 G12 anhand dieser Messwerte das passendere Performance-Profil. Der ältere Contabo VPS L bietet dagegen erheblich mehr RAM (~29,4 GiB vs. 8 GB) und Storage (~825 GB vs. 256 GB) – Argumente, die je nach Einsatzszenario entscheidend sein können.
Bei Server- und Hosting-Optimierungsprojekten ist die Serverauswahl nur ein Baustein. Stack-Konfiguration (PHP-FPM-Pool-Größe, MariaDB InnoDB Buffer Pool, Redis, Caching-Schichten) hat in der Praxis oft mehr Einfluss auf die gemessene WordPress-Performance als der reine Hardware-Unterschied.
Häufige Fragen
Sind 4 CPU-Kerne für WordPress ausreichend?
Ja – wenn die Kerne modern und schnell sind. Für drei WordPress-Websites mit Page-Cache, Object Cache (Redis) und OPcache trifft PHP-FPM nur einen Bruchteil der Requests. 4 schnelle Kerne sind in diesem Szenario besser als 8 langsame.
Was ist für WordPress wichtiger: CPU oder RAM?
Beides ist wichtig, aber für unterschiedliche Engpässe. CPU-Single-Core-Leistung bestimmt die Ausführungsgeschwindigkeit eines einzelnen PHP-Requests. RAM bestimmt, wie viele parallele PHP-FPM-Worker, wie groß der MariaDB-Buffer-Pool und wie viel Redis-Cache betrieben werden kann. Ab ~8 GB RAM für drei WordPress-Websites ist der nächste Engpass meist die CPU.
Braucht WordPress NVMe?
Nicht zwingend – aber schnelle IOPS und niedrige Latenzen bei kleinen (4K) zufälligen Zugriffen helfen dem Datenbankbetrieb messbar. Im konkreten Test erreichte das NVMe-System ~3,2× höhere kombinierte 4K-IOPS. Mit gutem Caching (Redis, Page-Cache) wird Storage als Engpass stark reduziert.
Was sind IOPS und warum sind sie für WordPress wichtig?
IOPS misst, wie viele kleine Lese-/Schreibvorgänge ein Storage-System pro Sekunde verarbeiten kann. WordPress und MariaDB erzeugen viele kleine, zufällige I/O-Zugriffe. Hohe 4K-IOPS reduzieren Wartezeiten bei diesen Operationen – direkt messbar im TTFB bei Cache-Misses.
Ist ein Root Server besser als ein VPS für WordPress?
Ein dedizierter Root Server bietet physisch exklusive CPU-Kerne ohne Überbuchungsrisiko. Ein guter VPS mit dedizierten Kernen kann ähnliche Garantien bieten. Der Unterschied liegt in den Vertragsbedingungen und der Host-Überbuchungspraxis.
Wie viel RAM benötigt Plesk mit drei WordPress-Websites?
Als Richtwert: Plesk-Basis ~512 MB, drei PHP-FPM-Pools je ~256–512 MB, MariaDB InnoDB Buffer Pool ~512 MB–1 GB, Redis ~128–256 MB, OPcache ~128 MB, Systemreserve ~512 MB. Gesamt: 4–6 GB für stabilen Betrieb mit moderatem Traffic. 8 GB bieten Spielraum für Lastspitzen.
Warum ist Single-Core-Leistung für PHP wichtig?
Ein PHP-FPM-Worker verarbeitet einen Request als einzelner Prozess auf einem CPU-Kern. WordPress lädt Plugins, rendert Templates und führt Datenbankabfragen sequenziell aus. Ein schnellerer einzelner Kern verkürzt die PHP-Ausführungszeit pro Request direkt.
Autor: Manuel Kuhn, WordPress Performance Engineer & Linux-Serveradministrator, Hosting-Fixers.de – August 2026