Server-CPU-Benchmarking für PHP: Tests für reale Webhosting-Workloads

Was ein PHP-Benchmark beantworten soll

Ein PHP CPU Benchmark kann zunächst zeigen, wie lange ein System für eine festgelegte Rechenaufgabe benötigt. Das ist besonders nützlich, wenn eine einzelne Anfrage viel Zeit mit PHP-Berechnungen verbringt. Eine höhere Single Core Performance kann die Bearbeitung solcher Arbeit verkürzen; aus einem CPU-Wert allein lässt sich aber nicht die Antwortzeit einer ganzen Website ableiten.

Eine zweite Frage betrifft das Verhalten der Anwendung bei gleichzeitigen Zugriffen: Wie viele korrekte Antworten liefert sie pro Sekunde, und wie lange warten Nutzer dabei? Dafür ist ein Webhosting Benchmark über HTTP sinnvoll. Er erfasst den Weg durch Webserver und PHP sowie gegebenenfalls Datenbank, Cache und Netzwerk. Gerade diese Mischung macht ihn praxisnah, verhindert aber eine isolierte Aussage über die CPU.

Die dritte Frage ist die nach dem Engpass. Wartet eine Anfrage beispielsweise auf eine Datenbankabfrage, kann eine schnellere Rechenaufgabe wenig über ihre Gesamtzeit aussagen. Auch ein Cache verändert das Ergebnis: Wird eine Seite bereits vor PHP vollständig ausgeliefert, misst der Aufruf nicht die Ausführung der dynamischen Anwendung.

Unter paralleler Last kann außerdem der PHP-FPM-Pool begrenzen, wie viele Anfragen gleichzeitig bearbeitet werden. Seine Statusseite liefert unter anderem Hinweise auf belegte Prozesse und wartende Anfragen. Eine wachsende Warteschlange ist deshalb ein Anlass zur Diagnose, kein unmittelbarer Beweis für eine zu langsame CPU.

Für die Hosting-Wahl hilft es, diese Fragen getrennt zu betrachten: erst die vergleichbare Arbeitseinheit, dann die Anwendung bei geringer und höherer Last und schließlich die Ressourcen, die das Ergebnis begrenzen. Wie CPU, Arbeitsspeicher und Storage grundsätzlich zusammenspielen, erläutert der Beitrag zu Hardware für High-Performance Webhosting.

CPU-Scores und Anwendungstests abgrenzen

Ein Mikrobenchmark wiederholt eine kleine, genau definierte Aufgabe. Mit PHPBench lässt sich beispielsweise eine Funktion zur Datenverarbeitung unter festgelegten Bedingungen untersuchen. Das Ergebnis hilft beim Vergleich dieser Funktion und ihrer Laufzeitumgebung; es beschreibt weder automatisch eine komplette Anfrage noch die Leistung eines CMS oder Shops.

Ein HTTP-Anwendungstest beantwortet eine andere Frage: Wie reagiert die gewählte Anwendung über den tatsächlich genutzten Webstack? Er berücksichtigt etwa PHP-FPM, Datenbank und Caches, soweit sie am getesteten Aufruf beteiligt sind. Damit eignet er sich für die Beurteilung eines Hosting-Angebots, kann aber nicht allein belegen, welche Komponente für einen Unterschied verantwortlich ist.

SPEC CPU ergänzt solche Tests durch standardisierte, rechenintensive Workloads. SPEC CPU 2026 enthält Integer- und Floating-Point-Suiten sowie Speed- und Rate-Ergebnisse. Speed bezieht sich auf die Zeit für Aufgaben, Rate auf den Durchsatz. Ein Speed-Wert ist nicht automatisch ein reiner Single-Core-Wert: SPEC weist bei Integer-Speed-Tests der 2026er Suite auf zusätzliche Parallelität hin.

Für einen belastbaren SPEC-Vergleich müssen Suite, Metrik und die Ergebnisart base oder peak übereinstimmen. Ebenso zählt das vollständig getestete System: Neben dem Prozessor beeinflussen unter anderem Speicher, Compiler und Konfiguration das Resultat. Veröffentlichte Werte sind daher keine isolierte Eigenschaft des CPU-Modells und ersetzen keinen PHP-Test.

SPEC CPU 2017 und CPU 2026 verwenden unterschiedliche Testsuiten; ihre Zahlen gehören nicht auf dieselbe Skala. Wer eine Vorauswahl trifft, sollte deshalb den vollständigen Ergebnisbericht statt einer verkürzten Rangliste vergleichen. Ob ein Kandidat für die eigene Anwendung geeignet ist, zeigt anschließend erst ein passend angelegter Anwendungstest.

Vergleichbare Testbedingungen festlegen

Ein fairer Vergleich beginnt mit derselben Anwendungsversion und einem vergleichbaren Datenbestand. Auch die gewählte Route und ihre erwartete Antwort müssen übereinstimmen: Eine Produktseite mit vielen Datenbankzugriffen beantwortet eine andere Frage als eine einfache API-Funktion. Prüfe daher nicht nur, ob eine Antwort eintrifft, sondern auch, ob sie inhaltlich zur vorgesehenen Aufgabe passt.

Halte PHP-Version und Erweiterungen ebenso fest wie Webserver, PHP-FPM-Konfiguration und Datenbank. Der Netzwerkweg zwischen Lastgenerator und Anwendung gehört ebenfalls ins Protokoll. Unterschiedliche Wege oder Datenbankstandorte können die gemessene Antwortzeit verändern, selbst wenn die PHP-Ausführung auf beiden Systemen gleich schnell wäre.

Besonders wichtig ist die Trennung von CLI und PHP-FPM: Ein Test auf der Kommandozeile untersucht nicht automatisch dieselbe Laufzeitkonfiguration wie eine HTTP-Anfrage. Dokumentiere für beide Kontexte die tatsächlich verwendeten OPcache- und JIT-Einstellungen. Ihre Wirkung und Voreinstellungen hängen unter anderem von der PHP-Version ab; eine pauschale Annahme reicht für den Vergleich nicht aus.

Auch der Cache-Zustand muss vergleichbar sein. Ein kalter Cache und ein bereits aufgewärmter Cache beantworten unterschiedliche Fragen; beide können relevant sein, sollten aber getrennt ausgewertet werden. Gleiches gilt für Datenmenge und Testdaten: Ändert sich der Arbeitsumfang, kann ein Zeitunterschied nicht mehr sauber dem System zugeschrieben werden.

Notiere außerdem CPU-Modell, zugewiesene vCPUs und sichtbare Ressourcenlimits sowie die gewählte Last und die Zahl der Wiederholungen. Werden bewusst zwei unterschiedliche Hosting-Pakete verglichen, ist das Ergebnis eine Aussage über deren jeweilige Gesamtkonfiguration. Unterschiede bei Prozessor, Limits, Datenbank oder Caching dürfen dann nicht ohne weitere Diagnose allein als CPU-Vorteil interpretiert werden.

Passende Workloads und Messgrößen wählen

Die Wahl des Tests richtet sich nach der Frage, die du beantworten möchtest. Ein Mikrobenchmark untersucht eine begrenzte Rechenaufgabe; ein HTTP-Test bezieht den Weg durch den Webstack ein. SPEC-Ergebnisse ergänzen den Vergleich um standardisierte CPU-intensive Systemtests, ersetzen aber keinen Test der eigenen PHP-Anwendung.

Für eine einzelne dynamische Anfrage wählst du eine repräsentative Seite oder API-Route und beginnst mit geringer Parallelität. Die Route muss PHP tatsächlich ausführen: Eine vollständig aus einem vorgeschalteten Seiten-Cache gelieferte Antwort wäre zwar ein gültiger Cache-Test, sagt aber wenig über die PHP-Verarbeitung aus.

Für gleichzeitige Besucher prüfst du denselben Endpunkt bei mehreren festgelegten Laststufen. So lässt sich erkennen, ob sich Antwortzeiten und erfolgreicher Durchsatz mit zunehmender Parallelität verändern. Bei einer datenbankintensiven Route sollten Datenbestand, Datenbankstandort und Cache-Zustand zwischen den Vergleichsläufen gleich bleiben.

Eine CPU-lastige Funktion aus der Anwendung kannst du ergänzend mit PHPBench isoliert untersuchen, etwa eine Datenverarbeitung ohne Netzwerkzugriff. Ein besseres Ergebnis zeigt zunächst nur einen Vorteil für diese Funktion unter den gewählten Laufzeitbedingungen. Ob sich daraus ein spürbarer Vorteil für eine vollständige Seite ergibt, muss der Anwendungstest zeigen.

Staging-Test mit wrk durchführen

Teste nur mit ausdrücklicher Genehmigung in einer isolierten Staging-Umgebung. Richte eine ungefährliche, repräsentative lesende Route ein und verwende geeignete Testdaten. Lege vor dem Start eine maximale Last sowie Abbruchkriterien fest, etwa auftretende Fehler, Timeouts oder eine Beeinträchtigung anderer Dienste.

Der folgende Befehl ist für ein Terminal auf einer ausdrücklich dafür eingerichteten lokalen Staging-Instanz gedacht. Auf Port 8080 muss die vorbereitete Route erreichbar sein; der Befehl erzeugt tatsächlich Last und ist nicht für ein unbekanntes oder produktives System gedacht.

wrk -t2 -c4 -d30s --latency http://127.0.0.1:8080/

Der Aufruf verwendet zwei Lastgenerator-Threads, vier offene Verbindungen und eine Laufzeit von 30 Sekunden. Die Option --latency fordert eine detaillierte Latenzausgabe an. Vier Verbindungen sind dabei ein gewählter Startpunkt für dieses Beispiel, keine allgemeingültige Empfehlung für die Besucherzahl oder die Kapazität eines Servers.

Die reguläre Perzentilausgabe von wrk enthält jedoch kein p95. Für eine reproduzierbare p95-Auswertung speichere das folgende Lua-Skript auf dem Lastgenerator als percentiles.lua. Es gibt p50 und p95 aus der Latenzstatistik in Mikrosekunden aus; durch 1.000 geteilt ergeben sich Millisekunden.

function done(summary, latency, requests)
  io.write(string.format("p50: %.0f us\n", latency:percentile(50.0)))
  io.write(string.format("p95: %.0f us\n", latency:percentile(95.0)))
end

Starte für die eigentliche Messung denselben lokalen Staging-Test mit dem Skript. Der Dateipfad gilt für ein Terminal im Verzeichnis der Skriptdatei. Auch dieser Aufruf erzeugt Last; dokumentiere die beiden ausgegebenen Perzentile zusammen mit Fehlern und der separat geprüften Antwortqualität.

wrk -t2 -c4 -d30s --latency -s percentiles.lua http://127.0.0.1:8080/

Plane eine getrennte Aufwärmphase ein, bevor du die eigentlichen Messläufe protokollierst. Wiederhole anschließend jede festgelegte Laststufe und variiere möglichst die Reihenfolge der Vergleichssysteme. Halte fest, wie lange aufgewärmt wurde und ob sich der Cache zu Beginn der Messung im gewünschten Zustand befand.

Erhöhe die Verbindungszahl nur innerhalb der vereinbarten Grenzen und prüfe nach jeder Stufe die Abbruchkriterien. Beobachte auch den Lastgenerator: Ist er selbst ausgelastet, kann er das Ergebnis begrenzen. Prüfe Statuscodes und Antwortinhalte ergänzend; eine schnell ausgelieferte Fehlerseite oder falsche Antwort zählt nicht als erfolgreiche Anwendungsanfrage.

Laststufen und Ergebnisse dokumentieren

Ein Messprotokoll verbindet die Zahlen mit den Bedingungen, unter denen sie entstanden sind. Notiere für jeden Lauf die Umgebung, den Endpunkt, den Cache-Zustand und die Laststufe zusammen mit den Ergebnissen. Das folgende Raster nutzt unter anderem Größen, die wrk beziehungsweise die FPM-Statusseite bereitstellen; die inhaltliche Antwortprüfung musst du ergänzen.

Der Median beschreibt die Mitte der beobachteten Antwortzeiten. Das p95 ist der Wert, den 95 Prozent der gemessenen Antworten nicht überschreiten. Zusammen zeigen beide Größen, ob sich neben einer typischen Anfrage auch der langsamere Teil der Verteilung verändert. Interpretiere sie stets zusammen mit Fehlern und Timeouts.

Unterscheide eine feste Verbindungszahl von einer vorgegebenen Anfragerate. Bei einem verbindungsbasierten Test wie dem Beispiel können langsame Antworten dazu führen, dass über dieselben Verbindungen weniger neue Anfragen pro Sekunde erzeugt werden. Die gemessene Latenz beschreibt dann nicht ohne Weiteres das Verhalten bei einer unverändert hohen Ankunftsrate.

Vergleiche deshalb nur ausreichend ähnliche Lastpunkte: dieselbe Route und Antwortprüfung, vergleichbare Cache-Zustände sowie dasselbe Lastmodell und dieselbe Laststufe. Ein niedriger p95 bei geringer Parallelität ist nicht unmittelbar mit einem p95 unter Überlast vergleichbar. Berichte mehrere Läufe und deren Streuung, statt einen einzelnen günstigen Wert als Ergebnis auszugeben.

FPM und Ressourcenlimits untersuchen

Steigen bei zunehmender Last sowohl die Warteschlange als auch die p95-Antwortzeit, lohnt sich ein Blick auf den PHP-FPM-Pool. Vergleiche die aktuellen Werte für active processes, idle processes und listen queue mit der konfigurierten Obergrenze pm.max_children. Sind alle erlaubten Prozesse aktiv, keine frei und Anfragen warten, deutet das auf eine Poolgrenze oder lange beschäftigte Worker hin, aber nicht automatisch auf eine zu langsame CPU.

Die Anzeige max children reached dokumentiert dagegen ein früheres Erreichen der Prozessgrenze seit dem Poolstart. Sie belegt für sich allein weder eine aktuelle Warteschlange noch, dass alle vorhandenen Prozesse gerade beschäftigt sind. Ebenso bedeutet die maximale Zahl vorhandener Prozesse nicht, dass alle aktiv sind.

Worker können auch auf Datenbankabfragen oder andere externe Dienste warten. Vergleiche deshalb Poolstatus und CPU-Auslastung mit den beobachteten Antwortzeiten: Eine volle Warteschlange bei geringer CPU-Auslastung legt nahe, zunächst Wartezeiten und die Belegung der Worker zu untersuchen. Eine größere Poolzahl ist nicht automatisch die Lösung, weil zusätzliche Prozesse ebenfalls Ressourcen benötigen.

Die FPM-Statuswerte gelten für den jeweiligen Pool; Zähler werden bei einem Neustart zurückgesetzt. Halte daher Pool und Neustartzeitpunkt im Messprotokoll fest und vergleiche Zählerstände nur innerhalb eines passenden Zeitraums. Schütze eine aktivierte Statusseite vor unbefugtem Zugriff, da sie Betriebsinformationen über den Pool offenlegt.

Bei VPS und Shared Hosting beschreibt eine zugewiesene vCPU nicht ohne Weiteres einen exklusiven physischen Kern. Wo cgroup-v2-Daten zugänglich sind, zeigt cpu.max die konfigurierte CPU-Bandbreitenbegrenzung; cpu.stat kann unter anderem Zähler für Throttling enthalten. Änderungen dieser Zähler während eines Laufs helfen bei der Diagnose einer wirksamen Begrenzung.

Prüfe nach Möglichkeit auch übergeordnete cgroups: Eine dort gesetzte Grenze kann die verfügbare Rechenzeit beeinflussen, selbst wenn die unmittelbar sichtbare Konfiguration großzügig wirkt. Nicht jeder Zähler bildet geerbte Begrenzungen vollständig ab. Fehlen diese Informationen im Hosting-Paket, gehört die eingeschränkte Sichtbarkeit ausdrücklich zu den Grenzen der Auswertung.

Streuung und Fehlmessungen erkennen

Ein einzelner Lauf kann ein zufällig günstiges oder ungünstiges Bild zeichnen. Wiederhole dieselben Laststufen zu dokumentierten Zeitpunkten und variiere nach Möglichkeit die Reihenfolge der Vergleichssysteme. Gerade bei geteilten Ressourcen kann die verfügbare Leistung schwanken; berichte deshalb neben einem typischen Ergebnis auch die beobachtete Streuung und die Zahl der Läufe.

Achte darauf, dass die Wiederholungen denselben Cache-Zustand und denselben Datenbestand verwenden. Ein Lauf mit warmem Seiten- oder Datenbank-Cache ist nicht unmittelbar mit einem kalten Lauf vergleichbar. Wenn eine scheinbar schnellere Antwort vollständig aus einem Seiten-Cache stammt, sagt sie wenig darüber aus, wie schnell PHP die dynamische Arbeit erledigt.

Ein CLI-Mikrobenchmark ist ebenfalls kein FPM-Ergebnis: Er läuft in einem anderen Ausführungskontext und kann andere OPcache- oder JIT-Einstellungen verwenden. Dokumentiere die tatsächlich aktiven Einstellungen beider Laufzeiten getrennt, statt sie aus der PHP-Version abzuleiten. Ein Vorteil im Mikrotest muss sich im HTTP-Test der Anwendung nicht in gleicher Größe zeigen.

Zähle nur inhaltlich korrekte, erfolgreiche Antworten zum erfolgreichen Durchsatz. Schnelle Fehlerseiten oder Timeouts können einen Vergleich sonst erheblich verzerren. Prüfe bei auffälligen Abweichungen auch Datenbankwartezeiten, Änderungen im Cache und sichtbare Ressourcenlimits, bevor du den Unterschied allein der CPU zuschreibst.

Das Taktverhalten kann ebenfalls zur Streuung beitragen. Welche Frequenzregelung sinnvoll ist, hängt von Plattform und Last ab; eine pauschale Einstellung ersetzt keinen Vergleich unter denselben Bedingungen. Der Beitrag zum CPU Governor auf Hosting-Servern erläutert die Zusammenhänge für eine vertiefte Prüfung.

Ergebnisse für die Hosting-Wahl nutzen

Für überwiegend einzelne CPU-lastige Anfragen ist die Zeit pro Arbeitseinheit ein wichtiges Auswahlkriterium. Vergleiche dafür eine repräsentative PHP-Funktion unter dokumentierter Laufzeit und prüfe anschließend, ob sich der Vorteil auch bei der dynamischen HTTP-Route zeigt. Ein Mikrobenchmark beschreibt zunächst nur den getesteten Code, nicht das gesamte Hosting-Angebot.

Erwartest du viele gleichzeitige Besucher, reicht die schnelle Einzelanfrage nicht aus. Entscheidend ist zusätzlich, wie viele korrekte Antworten pro Sekunde das System bei einer festgelegten Laststufe liefert und wie sich die p95-Latenz innerhalb des akzeptierten Fehlerbereichs verhält. Ein System mit höherem Durchsatz ist für dein Projekt nicht automatisch besser, wenn seine langsamen Antworten die Anforderungen überschreiten.

Bei datenbank- oder cacheabhängigen Anwendungen gewichte den Anwendungstest stärker als einen CPU-Score. Eine typische Route mit vergleichbarem Datenbestand zeigt, wie das Zusammenspiel des Stacks unter den gewählten Bedingungen funktioniert. Ein SPEC-Ergebnis kann die Vorauswahl ergänzen, beschreibt aber ein getestetes System und ersetzt keinen PHP-Webhosting-Test.

Lege vor der Auswahl fest, welche Antwortzeiten, Fehlerraten und Laststufen für die Anwendung akzeptabel sind. Vergleiche anschließend nur Ergebnisse mit passendem Lastmodell und vergleichbarem Cache-Zustand. Unterschiedliche Hosting-Pakete bewertest du als Gesamtkonfigurationen; aus ihrem Abstand lässt sich der Anteil der CPU nicht ohne weitere Diagnose herauslösen.

Die Entscheidung gilt für den gemessenen Stand, nicht für jede spätere Anwendungsversion oder Zugriffsspitze. Wiederhole die relevanten Tests nach wesentlichen Änderungen an PHP, Anwendung, Datenbank, Cache oder Ressourcenlimits. So erkennst du, ob die zuvor ausreichenden Reserven unter den neuen Bedingungen weiterhin bestehen.