PHP-Laufzeit optimieren: OPcache, JIT und FPM-Worker

Ohne Opcode-Cache wiederholt PHP bei jeder einzelnen Anfrage dieselbe Arbeit: Dateien vom Dateisystem lesen, den Quelltext parsen, einen Syntaxbaum aufbauen und daraus Opcodes erzeugen. Erst dann beginnt die eigentliche Ausführung. Der OPcache legt das Ergebnis dieser Kompilierung im gemeinsamen Speicher ab, sodass sämtliche Worker-Prozesse darauf zugreifen. Ab der zweiten Anfrage entfallen Lesen, Parsen und Kompilieren -- übrig bleibt die Ausführung. Bei Anwendungen mit vielen kleinen Klassendateien, also bei praktisch jedem modernen Shop und jedem Framework, ist das der wirksamste Einzelschritt in der Laufzeitschicht.

Entscheidend ist die Dimensionierung, und dabei zählen drei Werte. opcache.memory_consumption legt fest, wie viel gemeinsamer Speicher zur Verfügung steht -- ab Werk 128 MB (PHP-Handbuch). opcache.max_accelerated_files begrenzt die Zahl der Dateien im Cache, ab Werk 10.000 (PHP-Handbuch); der gesetzte Wert wird intern auf die nächstgrößere Zahl einer festen Reihe aufgerundet (PHP-Handbuch), sodass 32.531 eine sinnvollere Angabe ist als eine krumme Zahl. opcache.interned_strings_buffer reserviert Platz für mehrfach verwendete Zeichenketten, ab Werk 8 MB (PHP-Handbuch); bei vielen Klassen, Übersetzungen und Konfigurationsschlüsseln wird das schnell knapp. Reicht einer der drei Werte nicht, verwirft der Cache Einträge und kompiliert nach -- und genau dann entsteht ein Effekt, der im Betrieb wie ein sprunghaft langsames Backend aussieht.

Ob die Dimensionierung trägt, lässt sich messen statt schätzen. Die Funktion opcache_get_status() liefert Trefferquote, belegten und freien Speicher, die Zahl der zwischengespeicherten Skripte sowie Zähler für Neustarts (PHP-Handbuch). Erfahrungsgemäß sollte die Trefferquote im laufenden Betrieb dicht an hundert Prozent liegen; deutlich niedrigere Werte bedeuten, dass PHP regelmäßig nachkompiliert. Noch aussagekräftiger sind die Neustart-Zähler: oom_restarts steht für Neustarts wegen erschöpftem Speicher, hash_restarts für einen vollen Dateitisch, manual_restarts für ausgelöste Leerungen. Steigen die ersten beiden im Betrieb, ist der Cache zu klein -- unabhängig davon, wie gut die Trefferquote im Mittel aussieht.

Der Opcode-Cache ist dabei nur die unterste von mehreren Cache-Ebenen. Darüber liegen Objekt-Cache, Seiten-Cache und die Auslieferung über vorgelagerte Schichten; wie diese Ebenen ineinandergreifen und welche Anfrage überhaupt bis zu PHP durchdringt, ordnet der Beitrag zu Caching-Strategien ein. Für eine Seite, die vollständig aus einem Seiten-Cache beantwortet wird, spielt die Laufzeitschicht keine Rolle -- für jede personalisierte Seite, jeden Warenkorb und jeden Login dagegen sehr wohl.

Seit PHP 7.4 gibt es eine Stufe über dem reinen Opcode-Cache: das Preloading (PHP-Handbuch). Über opcache.preload wird beim Start des Dienstes ein Skript ausgeführt, das eine Liste von Klassen einliest. Diese Klassen bleiben dauerhaft im gemeinsamen Speicher und stehen jeder Anfrage sofort zur Verfügung -- ohne Autoloader, ohne Dateisystemzugriff und mit bereits aufgelösten Vererbungsbeziehungen. Für Frameworks mit stabilem Kern ist das ein zusätzlicher Gewinn über den Opcode-Cache hinaus, weil selbst der Nachschlagepfad entfällt.

Der Preis ist Betriebsdisziplin. Vorgeladene Klassen sind an den Prozess gebunden: Eine Änderung an einer vorgeladenen Datei wirkt erst nach einem Neustart des FPM-Dienstes, unabhängig von der Zeitstempelprüfung. Außerdem gehört opcache.preload_user gesetzt, wenn der Dienst als root startet (PHP-Handbuch), und die Liste sollte den stabilen Kern umfassen, nicht den Anwendungscode, der sich wöchentlich ändert. In Shop-Projekten lohnt sich Preloading vor allem dort, wo der Framework-Kern groß und der Anteil kundenspezifischer Klassen überschaubar ist; für Shopware-Installationen ist das ein eigener Schritt hinter der Cache-Dimensionierung, kein Ersatz dafür.

PHP-FPM verwaltet einen Vorrat an Worker-Prozessen. Wie dieser Vorrat entsteht, legt die Direktive pm fest, und sie kennt drei Werte: static, dynamic und ondemand (PHP-Handbuch). Bei static läuft eine feste Anzahl Prozesse dauerhaft. Bei dynamic startet FPM eine Grundmenge und regelt zwischen einer Unter- und einer Obergrenze freier Prozesse nach. Bei ondemand existiert zunächst kein Prozess; die Prozesse entstehen bei Bedarf und werden nach einer Leerlaufzeit wieder beendet. Alle drei Modi lösen dieselbe Aufgabe, aber sie verteilen die Kosten unterschiedlich zwischen Speicherverbrauch und Startzeit.

Über allen Modi steht pm.max_children -- die Obergrenze gleichzeitig arbeitender Prozesse und damit die eigentliche Kapazitätsgrenze der Anwendung. Dieser Wert ist keine Wunschzahl, sondern das Ergebnis einer Rechnung: nutzbarer Arbeitsspeicher abzüglich dessen, was Datenbank, Cache-Dienst und Betriebssystem brauchen, geteilt durch den tatsächlichen Speicherbedarf eines Worker-Prozesses unter Last. Wird der Bedarf zu niedrig angesetzt, beginnt das Betriebssystem unter Last auszulagern -- und ein auslagernder Server antwortet langsamer als einer mit einer knapp bemessenen Zahl an Workern.

Ergänzend begrenzt pm.max_requests, wie viele Anfragen ein Worker bearbeitet, bevor er sich beendet und neu startet; ab Werk steht der Wert auf 0, also unbegrenzt (PHP-Handbuch). Ein endlicher Wert ist eine pragmatische Absicherung gegen langsam wachsenden Speicherverbrauch in Erweiterungen. Er behebt die Ursache nicht, hält den Prozessvorrat aber gesund. Vergleichbares Wachstum gibt es auf der Browserseite, wo es sich in langen Sitzungen als zunehmende Trägheit äußert -- beschrieben im Beitrag zu Speicherlecks im Frontend.

Die häufigste Fehlmessung in dieser Schicht ist der Einzelabruf. Man ändert einen Wert in der Konfiguration, lädt die Seite im Browser neu, sieht eine bessere Zahl und schreibt sie in den Bericht. Das Problem: Der erste Abruf nach einem Neustart trifft einen leeren Opcode-Cache, der zweite einen warmen, und keiner von beiden sagt etwas über das Verhalten bei zwanzig gleichzeitigen Nutzern. Belastbar wird die Messung erst mit drei Zutaten -- einem definierten Aufwärmzustand, wiederholter Last mit realistischer Parallelität und einer Auswertung über Perzentile statt über Mittelwerte.

Der Mittelwert verdeckt genau den Effekt, um den es hier geht. Wenn neun von zehn Anfragen einen freien Worker finden und die zehnte wartet, bleibt der Durchschnitt ruhig, während das 95. Perzentil deutlich ausschlägt. Deshalb gehören der Wert bei 75 und bei 95 Prozent in jeden Vorher-Nachher-Vergleich, zusammen mit der Angabe, unter wie vielen gleichzeitigen Anfragen gemessen wurde. Wie sich Labor- und Feldmessung dabei ergänzen und warum beide gebraucht werden, ordnet der Beitrag zu Felddaten und Labordaten ein.

Damit die Verbesserung bleibt, gehört sie in die laufende Kontrolle. Ein Schwellwert für die Antwortzeit im Auslieferungsprozess meldet Rückschritte, bevor sie im Feld ankommen -- eine Erweiterung, die sich in bestehende Abläufe einfügen lässt und im Beitrag zum Performance-Budget in der CI beschrieben ist. Ohne diese Absicherung wandert die Konfiguration erfahrungsgemäß mit dem nächsten Serverumzug oder der nächsten Version wieder auf Standardwerte zurück.

Genau diese Reihenfolge arbeiten wir in einem Projekt ab. In der Performance-Analyse lesen wir zuerst die Laufzeitwerte aus, trennen Wartezeit, Kompilierzeit und Ausführungszeit voneinander und benennen, welcher Anteil überhaupt zu holen ist. Danach folgen die Eingriffe in der Reihenfolge ihres Nutzens: Cache-Dimensionierung, Deployment-Invalidierung, Prozessmodell, erst danach Preloading und -- sofern das Lastprofil es hergibt -- JIT. Für WordPress-Installationen und Shopware-Shops ist das ein eingespielter Ablauf, weil sich beide Systeme in der Laufzeitschicht ähnlich verhalten.

Wirtschaftlich lohnt sich der Aufwand dort, wo Wartezeit direkt auf Abschlüsse durchschlägt. Eine Verbesserung der mobilen Ladezeit um 0,1 Sekunden hob die Conversion-Rate im Einzelhandel um durchschnittlich 8,4 Prozent (Deloitte Ireland 2020), und über alle Branchen hinweg brechen im Mittel 70,22 Prozent (Baymard Institute) der Warenkörbe ab -- Wartezeit ist einer der Gründe, die sich technisch beeinflussen lassen. Wie sich Ladezeit und Umsatz insgesamt zueinander verhalten, führt der Beitrag zu Ladezeit, Conversion-Rate und Umsatz aus.

Der Aufwand für diese Schicht bleibt überschaubar, weil fast alles Konfiguration ist und kein Code-Umbau. Ein sauber dimensionierter Opcode-Cache, ein Deployment, das ihn zuverlässig zurücksetzt, ein Prozessmodell, das zum Lastprofil passt, und eine Messung, die Parallelität berücksichtigt: Damit ist der größte Teil gehoben, bevor exotischere Mittel überhaupt in Frage kommen. Bleibt danach noch Antwortzeit übrig, greifen die Ebenen darüber und darunter -- die TTFB-Optimierung an der Auslieferung und die Datenbank an der Abfrage. Welche Schritte dazugehören und wie ein solches Projekt abläuft, zeigt die Übersicht der Performance-Leistungen.