PHP-FPM Status Page zur Performanceanalyse nutzen

Was die Statusseite über den Pool zeigt

Die PHP-FPM-Statusseite zeigt, wie ein bestimmter Pool PHP-Anfragen verarbeitet: unter anderem, wie viele Prozesse aktiv oder frei sind und ob Anfragen warten. Voraussetzung ist, dass die Anwendung tatsächlich von PHP-FPM bedient wird. Die mit der Kommandozeile angezeigte PHP-Version allein belegt weder das noch die Version des zuständigen FPM-Dienstes.

Ermittle deshalb zuerst die eingesetzte FPM-Version und den Pool, an den der Webserver die Anwendung weiterleitet. Dazu gehören der verwendete Unix-Socket oder TCP-Listener und das Routing im zuständigen Virtual Host. Diese Zuordnung ist wichtig, damit eine spätere Statusabfrage nicht versehentlich einen anderen Pool beschreibt.

Betreibt ein Server mehrere Pools, gilt die Ausgabe jeweils für den abgefragten Pool und nicht automatisch für alle PHP-Anwendungen. Im Shared Hosting fehlen dir möglicherweise Rechte für die Pool- oder Webserverkonfiguration. Dann bist du darauf angewiesen, dass der Anbieter die Statusseite oder vergleichbare Kennzahlen geschützt bereitstellt.

Ein Abruf ist zunächst eine Momentaufnahme: Kurze Warteschlangen können zwischen zwei Abfragen entstehen und wieder verschwinden. Andere Werte zählen Ereignisse seit dem FPM-Start; bei einem Neustart werden sie zurückgesetzt. Speichere für einen aussagekräftigen Verlauf deshalb Abrufzeit und Poolidentität zusammen mit den Werten.

Die Seite erklärt nicht die gesamte Wartezeit im Browser. Netzwerk, Webserver, Datenbank und externe Dienste können ebenfalls zur Antwortzeit beitragen. Sie ist daher ein Ausgangspunkt für die Diagnose des PHP-FPM-Pools, kein vollständiger Leistungstest der Website.

Worker und Prozessmanager verstehen

Der Prozessmanager bestimmt, wie der Pool seine Worker bereitstellt. Bei static bleibt ihre Anzahl fest. dynamic passt die Anzahl innerhalb konfigurierter Grenzen an den Bedarf an; ondemand startet Prozesse bei Bedarf. Welche freien Kapazitäten du erwartest, hängt somit auch von der eingestellten Betriebsart ab.

Ein aktiver Prozess bearbeitet gerade eine Anfrage; ein freier Prozess steht für Arbeit bereit. Viele aktive Worker sind nicht automatisch ein Fehler: Ein ausgelasteter Pool kann Anfragen zügig abarbeiten. Aussagekräftiger wird die Beobachtung, wenn gleichzeitig Anfragen warten, Antwortzeiten steigen und kaum freie Prozesse verfügbar sind.

Auch eine kurzzeitig leere Reserve ist für sich genommen noch kein Beweis für einen dauerhaften Engpass. Vergleiche wiederholte Abrufe mit dem konfigurierten Prozesslimit und den Zeiten, zu denen Nutzer tatsächlich Verzögerungen bemerken. So unterscheidest du eine kurze Lastspitze eher von einer wiederkehrenden Überlastung.

Mehr Worker können mehr Anfragen parallel bearbeiten, benötigen aber zusätzlichen Speicher und können Datenbanken oder externe Dienste stärker belasten. Warten viele Prozesse auf dieselbe langsame Abhängigkeit, beseitigt eine höhere Grenze die Ursache nicht. Prüfe deshalb Ressourcen und Request-Dauer, bevor du pm.max_children änderst.

Für die Einordnung der Zuständigkeiten im Hosting-Stack hilft der Vergleich von NGINX Unit und PHP-FPM. Er ergänzt die Architekturperspektive; die konkreten Statuswerte und Prozessmanager-Einstellungen musst du weiterhin am tatsächlich eingesetzten FPM-Pool prüfen.

Statuszugriff und FastCGI absichern

Die Statusausgabe kann sensible Informationen über Anfragen und Ressourcen offenlegen. Insbesondere Prozessdetails können Request-URIs enthalten, die Rückschlüsse auf aufgerufene Funktionen oder übermittelte Parameter zulassen. Behandle die Seite daher als Diagnosezugang und nicht als öffentliches Status-Dashboard.

Beschränke den HTTP-Zugriff auf interne Anfragen oder ausdrücklich bekannte Client-IP-Adressen. Prüfe dabei, welche Adresse der Webserver tatsächlich als Client sieht, wenn ein Proxy vorgeschaltet ist. Der Schutz muss für das Routing der Statusseite gelten und sollte vor einer Freigabe überprüft werden.

Sichere unabhängig davon den FastCGI-Zugang selbst ab. Bei einem Unix-Socket sind Eigentümer und Berechtigungen relevant; bei TCP sind Netzwerkbindung und zugelassene Clients zu prüfen. Eine Sperre im Webserver schützt keinen FastCGI-Port, der separat aus einem unzuverlässigen Netz erreichbar ist.

Das PHP-Projekt dokumentiert mit CVE-2026-6735 eine XSS-Schwachstelle in der FPM-Statusausgabe. Korrigierte Versionen umfassen PHP 8.4.21 und 8.5.6. Prüfe für andere Versionszweige und Distributionspakete den jeweiligen Sicherheitsstand beziehungsweise zurückportierte Patches, statt allein aus der angezeigten Versionsnummer auf den Schutz zu schließen.

Ein Update ersetzt die Zugriffsbeschränkung nicht: Auch eine korrigierte Statusseite kann weiterhin betriebliche Details preisgeben. Halte sowohl den HTTP-Zugang als auch den Listener auf den vorgesehenen Nutzerkreis begrenzt und berücksichtige diese beiden Schutzschichten bei späteren Änderungen am Routing.

Statusseite geschützt bereitstellen

Ermittle zunächst, welcher FPM-Pool die betreffende Anwendung verarbeitet und über welchen Socket oder welche TCP-Adresse der Webserver ihn erreicht. Bei mehreren Pools gehört die Statusabfrage zu dem Pool, an den sie weitergeleitet wird. Die PHP-Version der Kommandozeile allein zeigt nicht, welcher FPM-Dienst für die Anwendung zuständig ist.

In der Konfigurationsdatei des zuständigen Pools aktiviert der folgende Auszug den Statuspfad. Er ist keine PHP-Datei, die du im Dokumentenverzeichnis anlegen musst. Der Auszug ist ein Konfigurationsvorschlag und setzt voraus, dass du die Poolkonfiguration bearbeiten darfst.

pm.status_path = /fpm-status

Richte im Webserver eine passende Route ein, die Anfragen an diesen Pfad direkt per FastCGI an den ermittelten Pool weiterleitet. Das gewöhnliche Anwendungs-Routing darf die Anfrage nicht abfangen. Beschränke den HTTP-Zugriff auf interne Anfragen oder bekannte Client-IP-Adressen und sichere den FastCGI-Socket unabhängig davon über Berechtigungen beziehungsweise Netzwerkbindung und zugelassene Clients ab.

Prüfe vor dem freigegebenen Rollout sowohl die Webserver- als auch die FPM-Konfiguration mit den in deiner Umgebung vorgesehenen Prüfverfahren. Vergewissere dich, dass du den richtigen Dienst und Pool änderst und dass die Zugriffsbeschränkung auch für den Statuspfad greift. Ein bloß gesetzter Pfad macht die Ausgabe noch nicht über HTTP erreichbar.

Für eine bereits eingerichtete, lokal geschützte Umgebung liest der folgende Terminalbefehl die JSON-Ausgabe. Er setzt voraus, dass unter der angegebenen Adresse ein passender lokaler HTTP-Virtual-Host erreichbar ist. Andernfalls musst du Adresse und Host-Routing sowie gegebenenfalls TLS an deine Umgebung anpassen; der Abruf verändert keine Konfiguration.

curl --fail --silent --show-error 'http://127.0.0.1/fpm-status?json'

Kontrolliere in der Antwort insbesondere den Poolnamen. Eine Fehlermeldung oder unerwartete Anwendungsausgabe kann auf ein unpassendes Routing hinweisen; auch eine Zugriffssperre kann den Abruf verhindern. Prüfe dann die zuständige Webserver-Konfiguration und die Logs, statt den Schutz vorschnell zu entfernen.

Kennzahlen richtig lesen und berechnen

Die Statuswerte beschreiben unterschiedliche Zeiträume: Manche zeigen den Zustand beim Abruf, andere zählen Ereignisse oder halten einen Höchstwert seit dem Start fest. Für eine Diagnose ist diese Unterscheidung wichtiger als ein einzelner auffälliger Wert. Die folgende Tabelle ordnet die zentralen Angaben ein.

Für eine Verbindungsrateziehst du zwei Werte von accepted conn voneinander ab und teilst die Differenz durch die verstrichene Zeit. Hypothetisches Rechenbeispiel, keine Messung: Steigt der Zähler innerhalb von 60 Sekunden von 12.000 auf 12.600, ergeben sich im Mittel zehn angenommene Verbindungen pro Sekunde. Daraus lassen sich weder Seitenaufrufe noch Anwendungslatenz unmittelbar ableiten.

Speichere mit jedem Messpunkt Zeit und Poolidentität. Nach einem FPM-Neustart werden die Statuswerte zurückgesetzt; eine Differenz über diesen Bruch hinweg ist deshalb keine gültige Rate. Erkenne einen gesunkenen Zähler beziehungsweise einen geänderten Startzeitpunkt und beginne die Berechnung für den neuen Zeitraum erneut.

Bei max children reached ist der Prozessmanager entscheidend: Die Beispielkonfiguration von PHP 8.4.21 beschreibt den Zähler für dynamic und ondemand. Bei static darfst du einen Nullwert nicht als Beweis für freie Kapazität werten. Für slow requests müssen Schwelle und Slowlog passend eingerichtet sein; die Schwelle bestimmt, welche langen Anfragen überhaupt erfasst werden.

Ausgabeformate und Prozessdetails vergleichen

Die kurze Ausgabe eignet sich für einen Überblick über den gesamten Pool. Für die Auswahl des Formats ist entscheidend, ob du Werte von Hand lesen oder regelmäßig durch ein Monitoring-System verarbeiten willst. Der Parameter full erweitert die Ausgabe um Prozessdetails; er ist kein eigenständiges Austauschformat.

Das PHP-Handbuch dokumentiert außerdem XML und HTML. Prüfe bei automatisierten Abrufen die tatsächlich installierte FPM-Version und ihre Ausgabe, bevor du auf bestimmte Felder oder Prozessdetails angewiesen bist. Insbesondere solltest du die Kombination aus OpenMetrics und full in der eigenen Version prüfen, statt Einzelprozessdaten pauschal vorauszusetzen.

Die Request-Dauer in der Full-Ausgabe steht in Mikrosekunden. Bei einem aktiven Prozess bezeichnet sie die Dauer der aktuell bearbeiteten Anfrage; bei einem inaktiven Prozess bezieht sie sich auf die zuletzt bearbeitete Anfrage. Ein hoher Wert bei einem freien Worker bedeutet daher nicht, dass dieser gerade noch mit der Anfrage beschäftigt ist.

Die Felder last request cpu und last request memory werden bei beschäftigten Prozessen als null ausgegeben, weil ihre Auswertung erst nach Abschluss der Anfrage erfolgt. Diese Nullwerte belegen somit keinen fehlenden CPU- oder Speicherverbrauch. Wiederholte Abrufe können zeigen, ob ein Prozess länger beschäftigt bleibt; sie ersetzen aber kein vollständiges Anwendungs-Tracing.

Warteschlangen und langsame Requests untersuchen

Steigt die Warteschlange wiederholt, während viele Prozesse aktiv und nur wenige frei sind, ist ein ausgelasteter Pool eine plausible Arbeitshypothese. Ein einzelner Abruf reicht dafür nicht: Vergleiche mehrere Zeitpunkte und achte darauf, ob gleichzeitig die Antwortzeiten für Anfragen steigen. Der Höchstwert der Warteschlange allein sagt nicht, ob gerade noch Anfragen warten.

Gleiche den Zeitraum mit FPM-Logs, CPU-Auslastung und verfügbarem Speicher ab. Beziehe auch Datenbank, Cache und externe Dienste ein: Wartet PHP auf eine langsame Abhängigkeit, bleiben Worker beschäftigt, obwohl zusätzliche CPU-Leistung allein das Problem nicht lösen muss. Die Statusseite zeigt die Belegung, aber nicht zuverlässig deren Ursache.

Rufe die geschützte Full-Ausgabe während einer auffälligen Phase wiederholt ab. Eine lange Request-Dauer bei demselben aktiven Prozess kann auf einen länger beschäftigten Worker hinweisen; prüfe dabei den Prozesszustand, denn bei einem inaktiven Prozess bezieht sich die Dauer auf dessen letzte Anfrage. PID, URI und Script helfen bei der Zuordnung, ergeben aber keinen vollständigen Trace.

Gerade bei einem Front-Controller kann derselbe Scriptname viele unterschiedliche Anwendungsfunktionen abdecken. Ergänze die Beobachtung daher um Anwendungs-Tracing und einen passend eingerichteten Slowlog. Dessen Schwelle bestimmt, welche langen Anfragen erfasst werden; ein fehlender Eintrag beweist nicht, dass alle Requests schnell waren. Wie du die Ausgaben vertiefend einordnest, zeigt der Beitrag zum Auswerten des PHP-FPM-Slowlogs.

Halte für den Abgleich das Zeitfenster und den betroffenen Pool fest. So kannst du etwa prüfen, ob eine langsame Datenbankabfrage zeitlich zu den belegten Workern passt oder ob die Warteschlange bereits vorher anwuchs. Eine Korrelation grenzt die Suche ein, ersetzt aber noch nicht die Prüfung des konkreten Requests.

Monitoring und Ausfälle der Statusseite

Für wiederkehrende Lastspitzen sind regelmäßige, geschützte Abrufe aussagekräftiger als gelegentliche Einzelprüfungen. JSON eignet sich für eine automatisierte Verarbeitung; OpenMetrics ist eine Alternative, wenn die installierte PHP-Version und der Monitoring-Client zusammenpassen. Speichere zu jedem Messpunkt den Zeitpunkt und die Identität des Pools, damit du nicht versehentlich verschiedene Pools vergleichst.

Behandle fehlende Abrufe als eigene Ereignisse und nicht als Nullwerte. Eine Lücke kann an Netzwerk, Zugriffsschutz oder dem Statusdienst liegen; sie belegt für sich weder einen leeren Pool noch einen Anwendungsausfall. Bewahre deshalb auch Fehler und Zeitüberschreitungen des Abrufs auf, damit die Lücke bei der späteren Auswertung sichtbar bleibt.

Erkenne außerdem Rücksetzungen kumulierter Zähler nach einem FPM-Neustart. Eine negative Differenz zwischen zwei Werten ist keine negative Verbindungsrate; beginne die Berechnung nach der Rücksetzung erneut und berücksichtige das unterbrochene Intervall. Auch Startzeit und Poolzuordnung helfen, einen solchen Bruch im Verlauf einzuordnen.

Läuft die Statusabfrage durch denselben Pool wie die Anwendung, kann sie bei ausgeschöpften Workern selbst warten. Für diese Situation bietet pm.status_listen einen separaten FastCGI-Listener mit unabhängig arbeitendem internem Pool. Er kann die Statusdiagnose ermöglichen, während der Hauptpool beschäftigt ist; er erhöht aber nicht dessen Verarbeitungskapazität.

Der zusätzliche Listener benötigt ein ausdrücklich zugeordnetes, geschütztes Webserver-Routing. Sichere auch seinen FastCGI-Zugang ab und prüfe nach einer freigegebenen Änderung, ob der Abruf tatsächlich den gewünschten Poolstatus liefert. So bleibt die Diagnose vom normalen Anwendungspfad getrennt, ohne die Statusdaten öffentlich zugänglich zu machen.

Befunde prüfen und Maßnahmen auswählen

Ein FPM-Ping und die Statusseite beantworten unterschiedliche Fragen. Der Ping zeigt, ob FPM auf die entsprechende Anfrage antwortet; er liefert keine gleichwertigen Informationen über freie Worker oder wartende Anfragen. Ein erfolgreicher Ping allein ist deshalb keine Entwarnung für die Auslastung des Anwendungspools.

Passen Prozesszahlen nicht zu Logs oder anderen Beobachtungen, prüfe zunächst Poolzuordnung, Abrufzeitpunkt und einen möglichen Neustart. Gleiche anschließend die Werte mit weiteren verfügbaren Prozess- und Betriebsdaten ab. Behandle die Abweichung zunächst als offenen Befund, statt daraus unmittelbar eine Ursache oder eine notwendige Konfigurationsänderung abzuleiten.

Zeigen wiederholte Full-Abrufe und Slowlog-Einträge dieselben langen Request-Muster, untersuche zuerst die betroffenen Anwendungspfade. Liegt die Verzögerung dagegen bei einer Datenbank oder einem externen Dienst, kann deren Analyse mehr bewirken als eine Änderung der Worker-Zahl. Entscheidend ist, ob die Maßnahme die beobachtete Ursache adressiert, nicht nur ein einzelnes Symptom.

Eine Anpassung von pm.max_children kommt infrage, wenn der Pool nachweislich an seiner Grenze arbeitet und CPU, Speicher sowie nachgelagerte Dienste zusätzliche Parallelität tragen können. Mehr Worker benötigen Ressourcen und können den Druck auf diese Dienste erhöhen. Eine universell passende Zahl gibt es deshalb nicht; die Betriebsart des Prozessmanagers gehört zur Bewertung.

Vergleiche nach einer freigegebenen Änderung denselben Pool unter möglichst vergleichbaren Lastbedingungen erneut: Warteschlange, Antwortzeiten, Fehler und Ressourcenverbrauch gehören zusammen. Halte auch fest, wenn eine Maßnahme keine Verbesserung bringt oder eine Abhängigkeit stärker belastet. Erst dieser Vorher-nachher-Vergleich erlaubt eine begründete Entscheidung über das weitere Vorgehen.