PHP 8 Performance: spürbare Geschwindigkeitssteigerung erreichen

PHP 8 brachte echte Sprünge bei Performance und Entwicklerproduktivität. Aber die Defaults holen das Potenzial nicht heraus. Mit der richtigen Konfiguration lassen sich bei rechenintensiven Workloads regelmäßig deutliche Steigerungen erreichen — ganz ohne Umbau der Anwendung. Besonders im Mittelstand, wo PHP-Anwendungen oft über Jahre laufen und ein Versionsprung sorgfältig vorbereitet werden muss, lohnt sich ein gezielter Blick auf OPcache, JIT und Preloading. Der Aufwand ist überschaubar, der Hebel je nach Workload beträchtlich — und im Gegensatz zu einer Code-Rewrite-Migration lassen sich die Hebel ohne Risiko stufenweise aktivieren.

JIT richtig nutzen

Der Just-In-Time-Compiler ist das Killer-Feature von PHP 8. Falsch konfiguriert kann er die Performance aber sogar verschlechtern.

; php.ini — sinnvolle Defaults
opcache.enable=1
opcache.jit_buffer_size=256M
opcache.jit=1235        ; tracing JIT, gut für CPU-lastige Logik
; opcache.jit=1254      ; für Web-Apps mit vielen Function Calls

JIT bringt am meisten bei rechenintensivem Code — Bildverarbeitung, Berechnungen, Parsing. Bei klassischen I/O-gebundenen Web-Requests ist der Effekt kleiner; dort zählt OPcache mehr. Den JIT-Puffer sollte man bewusst dimensionieren: Wer jit_buffer_size auf 256 MB setzt, reserviert diesen Speicher konsequent. Auf einem gut ausgestatteten Server kein Problem, auf einer kleinen VM wird es schnell eng. Wichtig ist auch, den JIT-Modus über opcache.jit aktiv zu setzen — ohne expliziten Wert compiliert PHP in manchen Builds nicht gerade weiter.

OPcache & Preloading

opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.validate_timestamps=0   ; in Produktion: Cache nicht ständig prüfen
opcache.preload=/var/www/preload.php

Preloading lädt Framework-Klassen einmal beim Start in den Speicher — jeder Request startet damit bereits "warm". Das lohnt sich besonders bei großen Frameworks wie Symfony oder Laravel, wo sonst hunderte Klassen pro Request geladen würden. Wer validate_timestamps in der Produktion abschaltet, muss Dateiänderungen aber aktiv bekannt machen — etwa über einen OPcache-Reset im Deployment, sonst läuft die alte Version weiter. Der Effekt ist messbar: Wo früher jeder Request ein Stück Compile-Zeit kostet, entfällt dieser Anteil fast vollständig.

Typische Stolperfallen

Die häufigsten Performance-Killer sitzen nicht im Code, sondern in der Konfiguration. Ein OPcache, dessen memory_consumption zu niedrig angesetzt ist, wirft im Stillen Einträge aus dem Cache — die vermeintliche Beschleunigung verpufft. Im Log steht davon oft nichts; man erkennt es nur an ungewöhnlich vielen Cache-Misses. max_accelerated_files sollte großzügig bemessen sein; 20.000 sind für mittelgroße Anwendungen ein solider Wert, große Monolithen brauchen mehr. Und Preloading verlangt, dass das Deployment die preload.php nach einem Update neu lädt, sonst arbeiten die Worker mit veraltetem Stand. Wer das vergisst, sucht seltsame Fehler, die nur nach einem Neustart verschwinden.

Messen statt raten

Jede Optimierung gehört verifiziert. Ein einfacher Benchmark zeigt, ob die JIT-Einstellung für den konkreten Workload etwas bringt:

$start = hrtime(true);
// ... Workload ...
printf("%.2f ms\n", (hrtime(true) - $start) / 1e6);

Die Regel bleibt: erst messen, dann konfigurieren, dann erneut messen. Pauschale "Speed-Tipps" aus dem Internet schaden öfter, als sie helfen. Im Zweifel entscheidet der echte Lasttest auf der Ziel-Hardware — und der Vergleich gegen die dokumentierte Baseline. Wer die Zahlen vor und nach der Umstellung festhält, hat außerdem eine Argumentationshilfe, wenn der nächste Versionsprung ansteht.