De PHP-FPM-statuspagina gebruiken voor prestatieanalyse

Wat de statuspagina over de pool laat zien

De PHP-FPM-statuspagina laat zien hoe een bepaalde zwembad Verwerkte PHP-verzoeken: onder andere hoeveel processen actief of vrij zijn en of er verzoeken in de wachtrij staan. Voorwaarde is dat de applicatie daadwerkelijk door PHP-FPM wordt bediend. De PHP-versie die via de opdrachtregel wordt weergegeven, geeft op zichzelf geen informatie over dit aspect, noch over de versie van de betreffende FPM-dienst.

Bepaal daarom eerst welke FPM-versie wordt gebruikt en naar welke pool de webserver de applicatie doorstuurt. Hierbij gaat het om de gebruikte Unix-socket of TCP-listener en de routing in de betreffende virtuele host. Deze toewijzing is belangrijk om te voorkomen dat bij een latere statusopvraging per ongeluk een andere pool wordt beschreven.

Als een server meerdere pools beheert, geldt de weergave telkens voor de opgevraagde pool en niet automatisch voor alle PHP-toepassingen. Bij shared hosting beschik je mogelijk niet over de benodigde rechten voor de configuratie van de pool of de webserver. In dat geval ben je afhankelijk van de provider om de statuspagina of vergelijkbare statistieken beveiligd beschikbaar te stellen.

Een opvraging is in de eerste plaats een Momentopname: Tussen twee opvragingen kunnen korte wachtrijen ontstaan en weer verdwijnen. Andere waarden tellen gebeurtenissen sinds de start van FPM; bij een herstart worden ze gereset. Sla daarom, voor een duidelijk overzicht, de opvraagtijd en de pool-ID samen met de waarden op.

Deze pagina geeft geen volledig beeld van de wachttijd in de browser. Ook het netwerk, de webserver, de database en externe diensten kunnen van invloed zijn op de responstijd. Het is daarom een uitgangspunt voor het diagnosticeren van de PHP-FPM-pool, en geen volledige prestatietest van de website.

Werknemers en procesmanagers begrijpen

De procesmanager bepaalt hoe de pool zijn workers inzet. Bij static blijft het aantal ervan gelijk. dynamic past het aantal binnen de geconfigureerde grenzen aan de behoefte aan; ondemand start processen indien nodig. Welke vrije capaciteit je kunt verwachten, hangt dus ook af van de ingestelde bedrijfsmodus.

Een actief proces is momenteel bezig met het verwerken van een verzoek; een vrij proces staat klaar om aan de slag te gaan. Een groot aantal actieve workers is niet per se een fout: een drukbezette pool kan verzoeken snel afhandelen. De situatie wordt pas zorgwekkend als er tegelijkertijd verzoeken in de wachtrij staan, de responstijden toenemen en er nauwelijks vrije processen beschikbaar zijn.

Zelfs een tijdelijk lege reserve is op zich nog geen bewijs van een blijvend tekort. Vergelijk herhaalde opvragingen met de geconfigureerde Proceslimiet en de momenten waarop gebruikers daadwerkelijk vertragingen opmerken. Zo kun je een korte piek in de belasting beter onderscheiden van een terugkerende overbelasting.

Meer workers kunnen meer verzoeken tegelijkertijd verwerken, maar hebben wel extra geheugen nodig en kunnen databases of externe diensten zwaarder belasten. Als veel processen wachten op dezelfde trage afhankelijkheid, lost een hogere limiet de oorzaak niet op. Controleer daarom de beschikbare middelen en de duur van de verzoeken voordat je pm.max_children veranderen.

Om de bevoegdheden binnen de hostingstack in kaart te brengen, helpt het om een vergelijking te maken tussen NGINX Unit en PHP-FPM. Het vormt een aanvulling op het architectuurperspectief; de concrete statuswaarden en instellingen van de procesmanager moet je nog steeds controleren in de daadwerkelijk gebruikte FPM-pool.

Status-toegang en FastCGI beveiligen

De statusweergave kan gevoelige informatie over verzoeken en bronnen onthullen. Met name procesdetails kunnen verzoek-URI’s bevatten die het mogelijk maken om conclusies te trekken over aangeroepen functies of verzonden parameters. Beschouw de pagina daarom als een diagnostische toegang en niet als een openbaar statusdashboard.

Beperk de HTTP-toegang op interne verzoeken of expliciet bekende IP-adressen van clients. Controleer daarbij welk adres de webserver daadwerkelijk als client ziet wanneer er een proxy tussen zit. De beveiliging moet gelden voor de routing van de statuspagina en moet worden gecontroleerd voordat deze wordt vrijgegeven.

Zorg in ieder geval voor de Toegang tot FastCGI zelf. Bij een Unix-socket zijn de eigenaar en de machtigingen van belang; bij TCP moeten de netwerkkoppeling en de toegestane clients worden gecontroleerd. Een blokkering op de webserver biedt geen bescherming voor een FastCGI-poort die afzonderlijk bereikbaar is vanuit een onbetrouwbaar netwerk.

Het PHP-project documenteert met CVE-2026-6735 een XSS-kwetsbaarheid in de FPM-statusuitvoer. Gecorrigeerde versies zijn onder meer PHP 8.4.21 en 8.5.6. Controleer voor andere versietakken en distributiepakketten de betreffende beveiligingsstatus of teruggeporteerde patches, in plaats van alleen op basis van het weergegeven versienummer te concluderen dat er bescherming is.

Een update vervangt de toegangsbeperking niet: zelfs een gecorrigeerde statuspagina kan nog steeds bedrijfsgegevens prijsgeven. Beperk zowel de HTTP-toegang als de listener tot de beoogde gebruikersgroep en houd rekening met deze twee beveiligingslagen bij latere wijzigingen in de routing.

De statuspagina beveiligd beschikbaar stellen

Bepaal eerst welke FPM-pool de betreffende applicatie verwerkt en via welke socket of welk TCP-adres de webserver deze bereikt. Bij meerdere pools hoort de statusaanvraag bij de pool waarnaar deze wordt doorgestuurd. De PHP-versie van de opdrachtregel geeft op zichzelf niet aan welke FPM-dienst verantwoordelijk is voor de toepassing.

In het configuratiebestand van de betreffende pool activeert het volgende fragment de Statuspad. Het is geen PHP-bestand dat je in de documentmap moet aanmaken. Het fragment is een configuratievoorstel en veronderstelt dat je de poolconfiguratie mag bewerken.

pm.status_path = /fpm-status

Stel op de webserver een geschikte route in die verzoeken naar dit pad rechtstreeks via FastCGI doorstuurt naar de vastgestelde pool. De gebruikelijke applicatierouting mag het verzoek niet onderscheppen. Beperk de HTTP-toegang tot interne verzoeken of bekende IP-adressen van clients en beveilig de FastCGI-socket onafhankelijk daarvan via machtigingen of netwerkbinding en toegestane clients.

Controleer vóór de officiële uitrol zowel de webserver- als de FPM-configuratie met behulp van de in jouw omgeving vastgestelde testprocedures. Zorg ervoor dat je de juiste service en pool wijzigt en dat de toegangsbeperking ook geldt voor het statuspad. Het louter instellen van een pad maakt de uitvoer nog niet bereikbaar via HTTP.

Voor een reeds ingestelde, lokaal beveiligde omgeving leest de volgende terminalopdracht de JSON-uitvoer. Hiervoor is vereist dat er op het opgegeven adres een geschikte lokale HTTP-virtual-host bereikbaar is. Anders moet je het adres en de host-routing, en indien nodig ook TLS, aanpassen aan je omgeving; het ophalen van de gegevens heeft geen invloed op de configuratie.

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

Controleer in het antwoord met name de naam van de pool. Een foutmelding of onverwachte uitvoer van de toepassing kan wijzen op een onjuiste routing; ook een toegangsbeperking kan het ophalen verhinderen. Controleer vervolgens de betreffende webserverconfiguratie en de logbestanden, in plaats van de beveiliging overhaast op te heffen.

Kerncijfers correct interpreteren en berekenen

De statuswaarden hebben betrekking op verschillende tijdsperioden: sommige geven de toestand weer op het moment van opvragen, andere tellen gebeurtenissen of registreren een maximumwaarde sinds de start. Voor een diagnose is dit onderscheid belangrijker dan een enkele opvallende waarde. In de volgende tabel worden de belangrijkste gegevens weergegeven.

Voor een verbindingssnelheidtrek je twee waarden af van accepted conn van elkaar af en deel het verschil door de verstreken tijd. Hypothetisch rekenvoorbeeld, geen meting: als de teller binnen 60 seconden stijgt van 12.000 naar 12.600, komt dat neer op gemiddeld tien veronderstelde verbindingen per seconde. Hieruit kunnen noch paginaweergaven, noch applicatielatentie direct worden afgeleid.

Sla bij elk meetpunt de tijd en de pool-identiteit op. Na een herstart van de FPM worden de statuswaarden gereset; een verschil over deze onderbreking heen is daarom geen geldige waarde. Detecteer een gedaalde teller of een gewijzigd starttijdstip en begin de berekening voor de nieuwe periode opnieuw.

Op max children reached is de procesmanager van cruciaal belang: de voorbeeldconfiguratie van PHP 8.4.21 beschrijft de teller voor ‘dynamic’ en ‘ondemand’. Bij ‘static’ mag je een waarde van nul niet beschouwen als bewijs van vrije capaciteit. Voor slow requests De drempel en de slowlog moeten correct zijn ingesteld; de drempel bepaalt welke lange verzoeken überhaupt worden geregistreerd.

Uitvoerformaten en procesdetails vergelijken

De korte versie is geschikt om een overzicht te krijgen van de gehele pool. Bij de keuze van het formaat is het van belang of je de waarden handmatig wilt aflezen of regelmatig via een monitoringsysteem wilt verwerken. De parameter full voegt procesdetails toe aan de uitvoer; het is geen op zichzelf staand uitwisselingsformaat.

De PHP-handleiding bevat bovendien documentatie over XML en HTML. Controleer bij geautomatiseerde opvragingen de daadwerkelijk geïnstalleerde FPM-versie en de uitvoer daarvan, voordat je vertrouwt op bepaalde velden of procesdetails. Let met name op de combinatie van OpenMetrics en full dit in de eigen versie controleren, in plaats van zomaar uit te gaan van gegevens over afzonderlijke processen.

De Duur van de aanvraag In de Full-uitgave wordt deze waarde in microseconden weergegeven. Bij een actief proces geeft deze de duur aan van het verzoek dat op dat moment wordt verwerkt; bij een inactief proces heeft deze betrekking op het laatst verwerkte verzoek. Een hoge waarde bij een vrije worker betekent daarom niet dat deze op dat moment nog bezig is met het verzoek.

De velden last request cpu en last request memory worden bij actieve processen als nul weergegeven, omdat ze pas na voltooiing van de aanvraag worden geëvalueerd. Deze nulwaarden duiden dus niet op een gebrek aan CPU- of geheugengebruik. Herhaalde controles kunnen aantonen of een proces langer actief blijft; ze zijn echter geen vervanging voor een volledige applicatietracing.

Wachtrijen en trage verzoeken onderzoeken

Als de wachtrij Als dit herhaaldelijk gebeurt terwijl er veel actieve processen zijn en er maar weinig vrij zijn, is een overbelaste pool een aannemelijke werkhypothese. Eén enkele controle is hiervoor niet voldoende: vergelijk meerdere tijdstippen en let erop of de responstijden voor verzoeken tegelijkertijd toenemen. De maximale waarde van de wachtrij alleen zegt nog niet of er op dat moment nog verzoeken in de wachtrij staan.

Vergelijk deze periode met FPM-logs, CPU-belasting en beschikbaar geheugen. Houd ook rekening met de database, cache en externe diensten: als PHP wacht op een trage afhankelijkheid, blijven workers bezig, hoewel extra CPU-vermogen op zich het probleem niet per se hoeft op te lossen. De statuspagina toont het gebruik, maar geeft niet altijd een betrouwbare indicatie van de oorzaak.

Roep de beveiligde volledige uitvoer herhaaldelijk op tijdens een opvallende fase. Een lange verzoekduur bij hetzelfde actieve proces kan wijzen op een worker die al langere tijd bezig is; controleer daarbij de processtatus, want bij een inactief proces heeft de duur betrekking op het laatste verzoek van dat proces. PID, URI en script helpen bij de toewijzing, maar leveren geen volledige trace op.

Juist bij een front-controller kan dezelfde scriptnaam veel verschillende toepassingsfuncties omvatten. Vul deze observatie daarom aan met applicatietracing en een passend geconfigureerde Slowlog. De drempelwaarde daarvan bepaalt welke lange verzoeken worden geregistreerd; het ontbreken van een vermelding betekent niet dat alle verzoeken snel waren. Hoe je de uitkomsten nader kunt interpreteren, wordt uitgelegd in het artikel over de Het PHP-FPM-slowlog analyseren.

Noteer voor de vergelijking het tijdvenster en de betreffende pool. Zo kun je bijvoorbeeld controleren of een trage databasequery qua tijd overeenkomt met de bezette workers, of dat de wachtrij al eerder aan het groeien was. Een correlatie beperkt de zoekopdracht, maar vervangt nog niet de controle van het concrete verzoek.

Monitoring en storingen van de statuspagina

Voor terugkerende piekbelastingen zijn regelmatige, beveiligde opvragingen zinvoller dan incidentele afzonderlijke controles. JSON is geschikt voor geautomatiseerde verwerking; OpenMetrics is een alternatief als de geïnstalleerde PHP-versie en de monitoringclient compatibel zijn. Sla voor elk meetpunt het tijdstip en de identiteit van de pool op, zodat je niet per ongeluk verschillende pools met elkaar vergelijkt.

Behandel ontbrekende opvragingen als afzonderlijke gebeurtenissen en niet als nulwaarden. Een leemte kan te wijten zijn aan het netwerk, de toegangsbeveiliging of de statusdienst; deze duidt op zichzelf noch op een lege pool, noch op een applicatiestoring. Sla daarom ook fouten en time-outs bij het ophalen op, zodat de leemte bij de latere analyse zichtbaar blijft.

Houd bovendien rekening met het terugzetten van gecumuleerde tellers na een FPM-herstart. Een negatief verschil tussen twee waarden betekent niet dat de verbindingssnelheid negatief is; begin de berekening na het resetten opnieuw en houd rekening met het onderbroken interval. Ook de starttijd en de pooltoewijzing helpen om een dergelijke onderbreking in het verloop te duiden.

Als de statusopvraging via dezelfde pool verloopt als de applicatie, kan deze zelf wachten wanneer de workers vol zijn. Voor deze situatie biedt pm.status_listen een aparte FastCGI-listener met een onafhankelijk werkende interne pool. Deze kan statusdiagnose mogelijk maken terwijl de hoofdpool bezet is; hij vergroot echter niet de verwerkingscapaciteit daarvan.

De extra listener heeft een expliciet toegewezen, beveiligde webserver-routing nodig. Beveilig ook de FastCGI-toegang en controleer na een goedgekeurde wijziging of de opvraging daadwerkelijk de gewenste poolstatus oplevert. Zo blijft de diagnose gescheiden van het normale applicatiepad, zonder dat de statusgegevens openbaar toegankelijk worden gemaakt.

Bevindingen beoordelen en maatregelen selecteren

Een FPM-ping en de statuspagina geven antwoord op verschillende vragen. De ping laat zien of FPM op het betreffende verzoek reageert; hij geeft geen vergelijkbare informatie over beschikbare workers of wachtende verzoeken. Een succesvolle ping alleen is daarom geen reden om ongerustheid over de belasting van de applicatiepool weg te nemen.

Als procescijfers niet overeenkomen met logbestanden of andere waarnemingen, controleer dan eerst de pooltoewijzing, het tijdstip van opvraging en of een herstart nodig is. Vergelijk vervolgens de waarden met andere beschikbare proces- en bedrijfsgegevens. Beschouw de afwijking in eerste instantie als een openstaande bevinding, in plaats van er direct een oorzaak of een noodzakelijke configuratiewijziging uit af te leiden.

Als herhaalde ‘Full’-opvragingen en slowlog-vermeldingen dezelfde lange verzoekpatronen vertonen, onderzoek dan eerst de betreffende applicatiepaden. Als de vertraging daarentegen bij een database of een externe dienst ligt, kan de analyse daarvan meer effect hebben dan een aanpassing van het aantal workers. Het is van cruciaal belang dat de maatregel de waargenomen oorzaak aanpakt, en niet alleen een afzonderlijk symptoom.

Een aanpassing van pm.max_children Dit is een optie als aantoonbaar is dat de pool op zijn limiet draait en de CPU, het geheugen en de daarachter liggende diensten extra parallelliteit aankunnen. Meer workers hebben meer resources nodig en kunnen de druk op deze diensten verhogen. Er is daarom geen algemeen geldend aantal; de werkwijze van de procesmanager moet bij de afweging worden meegenomen.

Vergelijk na het doorvoeren van een wijziging dezelfde pool opnieuw onder zo vergelijkbaar mogelijke belastingomstandigheden: wachtrij, responstijden, fouten en resourceverbruik horen bij elkaar. Noteer ook wanneer een maatregel geen verbetering oplevert of een afhankelijkheid zwaarder belast. Pas dan Voor-en-na-vergelijking maakt een weloverwogen beslissing over de verdere aanpak mogelijk.