Kurz gesagt: Der PHP JIT (Just-in-time-Compiler) übersetzt häufig ausgeführten PHP-Code während der Laufzeit in Maschinencode. Er kam mit PHP 8.0, ist Teil von OPcache und seit PHP 8.4 standardmäßig abgeschaltet. Rechenintensive Aufgaben werden damit deutlich schneller, typische Websites wie WordPress kaum. Den größeren Gewinn bringen OPcache, eine aktuelle PHP-Version und eine passend eingestellte Prozessverwaltung, und jede aktuelle Version bringt zugleich die nötigen Sicherheitskorrekturen.
Was ist der JIT-Compiler in PHP?
PHP ist eine interpretierte Sprache: Der Quelltext wird zunächst in Bytecode übersetzt, sogenannte Opcodes, und diese führt die Zend Engine aus. Ein JIT geht einen Schritt weiter. Er beobachtet, welche Codeabschnitte oft laufen, und übersetzt genau diese in Maschinencode für den Prozessor. Ab dann laufen sie ohne den Umweg über den Interpreter.
Das RFC zur Einführung beschreibt den JIT als nahezu eigenständigen Teil von OPcache. Der erzeugte Maschinencode liegt in einem zusätzlichen Bereich des gemeinsamen OPcache-Speichers. Mit PHP 8.4 hat das Projekt den JIT neu aufgebaut; laut Release-Seite basiert die neue Implementierung auf dem IR-Framework, einer gemeinsamen Zwischendarstellung für die Code-Erzeugung. Wie die Engine darunter arbeitet, erklärt die Zend Engine.
OPcache zuerst: die eigentliche Performance-Basis
Ohne OPcache übersetzt PHP jede Datei bei jeder Anfrage neu. OPcache hebt den Bytecode im gemeinsamen Speicher auf, sodass alle Worker ihn wiederverwenden. Für eine Website mit Content-Management-System ist das der mit Abstand wichtigste Hebel. Seit PHP 8.5 ist OPcache laut angenommenem RFC fest in PHP einkompiliert; die bekannten ini-Einstellungen steuern weiterhin, ob der Cache aktiv ist.
Wichtige Standardwerte laut Handbuch: opcache.enable=1, opcache.enable_cli=0, opcache.validate_timestamps=1 und opcache.revalidate_freq=2. Mit der letzten Einstellung prüft OPcache höchstens alle zwei Sekunden, ob sich Dateien geändert haben. Wer validate_timestamps abschaltet, muss nach jedem Deployment den Cache leeren oder PHP neu starten. Mehr dazu unter OPcache erklärt.
PHP JIT konfigurieren: Modi und Einstellungen
Der JIT wird über zwei Direktiven gesteuert:
| Direktive | Standard ab 8.4 | Standard vor 8.4 | Bedeutung |
|---|---|---|---|
opcache.jit |
disable |
tracing |
Modus des JIT |
opcache.jit_buffer_size |
64M |
0 |
Speicher für erzeugten Maschinencode, 0 schaltet den JIT ab |
Für opcache.jit kennt das Handbuch diese Werte: disable (ganz aus, zur Laufzeit nicht einschaltbar), off (aus, aber zur Laufzeit einschaltbar), tracing beziehungsweise on (für die meisten Nutzer empfohlen) und function. Daneben gibt es eine vierstellige Zahlenschreibweise für Feineinstellungen.
; JIT gezielt einschalten, z. B. für rechenintensive Worker
opcache.enable=1
opcache.jit=tracing
opcache.jit_buffer_size=64M
Ob der JIT läuft, zeigt der OPcache-Status:
php -i | grep -i "opcache.jit" # Einstellungen der CLI
php --ri "Zend OPcache" # Konfiguration der OPcache-Erweiterung
Beachten Sie, dass die Kommandozeile andere Einstellungen nutzen kann als PHP-FPM. Für den Webbetrieb zählt die Ausgabe von phpinfo() im FPM-Kontext, idealerweise nur intern abgerufen und danach wieder entfernt.
Was bringt der JIT in der Praxis?
Die Autoren des RFC haben gemessen: Das synthetische Skript bench.php lief mit JIT mehr als doppelt so schnell. Bei realen Anwendungen fiel der Gewinn klein aus; WordPress kam auf 326 statt 315 Anfragen pro Sekunde, der PHP-Parser lief etwa 1,3-mal so schnell. Das RFC sagt offen, dass der JIT reale Anwendungen wie WordPress nicht deutlich beschleunigt.
Der Grund liegt im Profil typischer Webanwendungen. Sie warten den Großteil der Zeit auf Datenbank, Dateisystem oder externe Dienste. Ein schnellerer Prozessorpfad hilft dort wenig. Profitieren können dagegen Bildverarbeitung in PHP, mathematische Berechnungen, Parser oder lang laufende Worker.
Performance ohne JIT: die wirksameren Hebel
Für Unternehmenswebsites und Shops lohnt sich diese Reihenfolge:
- Aktuelle PHP-Version: Neue Versionen bringen Optimierungen und vor allem Sicherheitskorrekturen.
- OPcache richtig dimensionieren: genug Speicher und Platz für alle Dateien der Anwendung.
- PHP-FPM passend einstellen:
pm.max_childrenan den verfügbaren Arbeitsspeicher anpassen, statt blind zu erhöhen. - Datenbank prüfen: langsame Abfragen finden, Indizes setzen.
- Caching auf Anwendungsebene: Seiten- oder Objektcache, wo das System es unterstützt.
- Messen statt raten:
request_slowlog_timeoutin PHP-FPM schreibt für langsame Anfragen einen Backtrace in das Slowlog.
JIT, Performance und Sicherheit
Performance und Sicherheit hängen enger zusammen, als es scheint. Erstens: Jede zusätzliche Komponente ist zusätzlicher Code. Das RFC zur Einführung nennt selbst das Risiko von Fehlern im JIT, in Code-Erzeugung und Registerzuteilung, sowie die schwerere Fehlersuche. Wer den JIT nicht messbar braucht, lässt ihn beim Standard disable.
Zweitens: OPcache und Worker halten Code im Speicher. Nach einem Sicherheitsupdate wie zu PHP2Shell laufen alte Prozesse mit altem Code weiter, bis sie neu gestartet sind. Ein Leeren des Caches allein ersetzt diesen Neustart nicht, denn die Lücken CVE-2026-109618 und CVE-2026-109619 stecken in der PHP-Binary selbst.
Drittens: Der beste Performance-Gewinn, eine aktuelle Version, ist zugleich die wichtigste Schutzmaßnahme. PHP 8.2 erreicht am 31.12.2026 das Ende der Unterstützung; wer jetzt auf 8.4 oder 8.5 wechselt, gewinnt beides. Wie wir Systeme dauerhaft schnell und gehärtet halten, beschreibt die Server-Härtung für PHP-Webserver.
Wie hilft PHP SOS konkret?
- Ist-Analyse: Wir lesen OPcache-, JIT- und FPM-Einstellungen aus und vergleichen sie mit Last und Arbeitsspeicher.
- Engpässe messen: Mit Slowlog und Serverkennzahlen finden wir, wo die Zeit tatsächlich verloren geht.
- Sicher konfigurieren: JIT nur dort, wo er nachweislich hilft; OPcache so, dass Deployments und Updates sauber greifen.
- Updates einplanen: Versionswechsel mit Test und dokumentiertem Neustart, damit Tempo und Patchstand stimmen.
Häufige Fragen
Ist der JIT in PHP standardmäßig aktiv?
Seit PHP 8.4 nicht mehr: Der Standardwert von opcache.jit ist disable. Vorher war tracing voreingestellt, dafür war der Puffer opcache.jit_buffer_size auf 0 gesetzt, wodurch der JIT ebenfalls nicht lief.
Macht der JIT WordPress schneller?
Kaum. Schon im RFC zur Einführung schreiben die Autoren, dass der JIT reale Anwendungen wie WordPress nicht deutlich beschleunigt. Ihr Messwert stieg von 315 auf 326 Anfragen pro Sekunde.
Brauche ich OPcache, wenn ich den JIT nicht nutze?
Ja. OPcache speichert den übersetzten Bytecode im gemeinsamen Speicher und spart bei jeder Anfrage das erneute Kompilieren. Das ist für fast jede PHP-Website der wichtigste Performance-Hebel. Seit PHP 8.5 ist OPcache fest in PHP eingebaut.
Ist der JIT ein Sicherheitsrisiko?
Mehr Code bedeutet mehr mögliche Fehler. Das RFC zur Einführung nennt selbst das Risiko von Fehlern im JIT und die schwerere Fehlersuche. Wer ihn nicht braucht, lässt ihn aus; wer ihn nutzt, sollte Updates besonders zügig einspielen.