Brug PHP-FPM-statussiden til ydeevneanalyse

Hvad statussiden viser om poolen

PHP-FPM-statussiden viser, hvordan en bestemt Pool Behandlede PHP-anmodninger: blandt andet hvor mange processer der er aktive eller ledige, og om der er anmodninger i kø. Forudsætningen er, at applikationen rent faktisk betjenes af PHP-FPM. Den PHP-version, der vises via kommandolinjen, angiver hverken dette eller versionen af den relevante FPM-tjeneste.

Find derfor først ud af, hvilken FPM-version der anvendes, og hvilken pool webserveren videresender applikationen til. Dette omfatter den anvendte Unix-socket eller TCP-listener samt routingen i den relevante virtuelle vært. Denne tilknytning er vigtig, så en senere statusforespørgsel ikke ved en fejltagelse beskriver en anden pool.

Hvis en server kører flere puljer, gælder udskriften kun for den pågældende pulje og ikke automatisk for alle PHP-applikationer. Ved delt hosting har du muligvis ikke rettigheder til at konfigurere puljen eller webserveren. I så fald er du afhængig af, at udbyderen stiller statussiden eller tilsvarende nøgletal til rådighed i en beskyttet form.

En hentning er først og fremmest en Øjebliksbillede: Der kan opstå korte køer mellem to forespørgsler, som igen forsvinder. Andre værdier tæller begivenheder siden FPM-opstarten; ved en genstart nulstilles de. For at få et meningsfuldt forløb bør du derfor gemme hentetidspunktet og poolidentiteten sammen med værdierne.

Siden forklarer ikke hele ventetiden i browseren. Netværk, webserver, database og eksterne tjenester kan også påvirke svartiden. Den er derfor et udgangspunkt for diagnosticering af PHP-FPM-puljen, ikke en fuldstændig ydelsestest af hjemmesiden.

At forstå arbejdere og procesledere

Procesmanageren bestemmer, hvordan puljen stiller sine arbejdere til rådighed. Ved static forbliver antallet uændret. dynamic tilpasser antallet til behovet inden for de konfigurerede grænser; ondemand starter processer efter behov. Hvilke ledige kapaciteter du kan forvente, afhænger derfor også af den indstillede driftsform.

En aktiv proces behandler netop en forespørgsel; en ledig proces står klar til at udføre arbejde. Et stort antal aktive arbejdere er ikke nødvendigvis et tegn på en fejl: En fuldt udnyttet pulje kan behandle forespørgsler hurtigt. Observationen bliver mere sigende, hvis der samtidig er forespørgsler, der venter, svartiderne stiger, og der næsten ikke er ledige processer til rådighed.

Selv en kortvarig tom reserve er i sig selv ikke noget bevis på en vedvarende flaskehals. Sammenlign gentagne hentninger med den konfigurerede Procesgrænse og de tidspunkter, hvor brugerne rent faktisk bemærker forsinkelser. På den måde kan du bedre skelne mellem en kortvarig belastningsspids og en tilbagevendende overbelastning.

Flere arbejdsprocesser kan behandle flere anmodninger sideløbende, men kræver ekstra hukommelse og kan belaste databaser eller eksterne tjenester i højere grad. Hvis mange processer venter på den samme langsomme afhængighed, løser en højere grænse ikke årsagen. Kontroller derfor ressourcerne og anmodningernes varighed, før du pm.max_children forandring.

For at få et overblik over ansvarsfordelingen i hosting-stakken kan det være nyttigt at sammenligne NGINX Unit og PHP-FPM. Det supplerer det arkitektoniske perspektiv; de konkrete statusværdier og indstillingerne i procesmanageren skal du fortsat kontrollere i den FPM-pool, der rent faktisk anvendes.

Sikring af statusadgang og FastCGI

Statusoplysningerne kan afsløre følsomme oplysninger om forespørgsler og ressourcer. Især procesdetaljer kan indeholde forespørgsels-URI’er, der giver mulighed for at udlede, hvilke funktioner der er blevet kaldt, eller hvilke parametre der er blevet overført. Betragt derfor siden som en diagnostisk adgang og ikke som et offentligt status-dashboard.

Begræns HTTP-adgang på interne forespørgsler eller udtrykkeligt angivne klient-IP-adresser. Kontroller i den forbindelse, hvilken adresse webserveren rent faktisk ser som klient, hvis der er en proxy foran. Beskyttelsen skal gælde for routingen af statussiden og bør kontrolleres, inden den frigives.

Uanset hvad skal du sikre dig FastCGI-adgang selv. For en Unix-socket er ejer og rettigheder relevante; for TCP skal netværksbinding og godkendte klienter kontrolleres. En blokering på webserveren beskytter ikke en FastCGI-port, der kan nås separat fra et upålideligt netværk.

PHP-projektet dokumenterer med CVE-2026-6735 en XSS-sårbarhed i FPM-statusudskriften. De rettede versioner omfatter PHP 8.4.21 og 8.5.6. For andre versionsgrene og distributionspakker bør du kontrollere den aktuelle sikkerhedsstatus eller tilbageporterede programrettelser i stedet for udelukkende at konkludere, at der er beskyttelse, ud fra det viste versionsnummer.

En opdatering erstatter ikke adgangsbegrænsningen: Selv en rettet statusside kan stadig afsløre driftsmæssige detaljer. Begræns både HTTP-adgangen og listeneren til den tiltænkte brugerkreds, og tag højde for disse to beskyttelseslag ved senere ændringer af routingen.

Gør statussiden tilgængelig med beskyttelse

Find først ud af, hvilken FPM-pool der håndterer den pågældende applikation, og via hvilken socket eller TCP-adresse webserveren får forbindelse til den. Hvis der er flere pools, henhører statusforespørgslen til den pool, som den videresendes til. PHP-versionen fra kommandolinjen viser ikke i sig selv, hvilken FPM-tjeneste der er ansvarlig for applikationen.

I konfigurationsfilen for den pågældende pool aktiverer følgende uddrag Statussti. Det er ikke en PHP-fil, som du skal oprette i dokumentmappen. Uddraget er et forslag til konfiguration og forudsætter, at du har tilladelse til at redigere poolkonfigurationen.

pm.status_path = /fpm-status

Opret en passende rute på webserveren, der videresender anmodninger til denne sti direkte via FastCGI til den udvalgte pool. Den almindelige applikationsrouting må ikke opfange anmodningen. Begræns HTTP-adgangen til interne anmodninger eller kendte klient-IP-adresser, og sikr FastCGI-socket uafhængigt heraf via tilladelser eller netværksbinding og godkendte klienter.

Kontroller både webserver- og FPM-konfigurationen inden den godkendte udrulning ved hjælp af de testprocedurer, der er fastlagt i dit miljø. Sørg for, at du ændrer den rigtige tjeneste og pool, og at adgangsbegrænsningen også gælder for statusstien. En blot angivet sti gør ikke udgangen tilgængelig via HTTP.

I et allerede konfigureret, lokalt beskyttet miljø læser følgende terminalkommando JSON-udskriften. Det forudsætter, at der er adgang til en passende lokal HTTP-virtuel vært på den angivne adresse. Ellers skal du tilpasse adressen, host-routing og eventuelt TLS til dit miljø; hentningen ændrer ikke konfigurationen.

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

Kontroller især poolnavnet i svaret. En fejlmeddelelse eller uventet output fra applikationen kan tyde på forkert routing; også en adgangsspærring kan forhindre hentningen. Kontroller derefter den relevante webserverkonfiguration og logfilerne, i stedet for at fjerne beskyttelsen forhastet.

Sådan læser og beregner man nøgletal korrekt

Statusværdierne beskriver forskellige tidsperioder: Nogle viser tilstanden på det tidspunkt, hvor de hentes, andre tæller hændelser eller registrerer en maksimumsværdi siden opstart. For en diagnose er denne skelnen vigtigere end en enkelt afvigende værdi. Den følgende tabel giver et overblik over de centrale oplysninger.

For en Forbindelseshastighedtrækker du to værdier fra accepted conn fra hinanden og deler forskellen med den forløbne tid. Hypotetisk regneeksempel, ingen måling: Hvis tælleren stiger fra 12.000 til 12.600 inden for 60 sekunder, giver det i gennemsnit ti antagede forbindelser pr. sekund. Heraf kan man hverken umiddelbart udlede sidevisninger eller applikationslatens.

Gem tid og pool-identitet for hvert målepunkt. Efter en genstart af FPM nulstilles statusværdierne; en forskel på tværs af dette brud er derfor ikke en gyldig hastighed. Registrer et fald i tælleren eller et ændret starttidspunkt, og start beregningen for den nye periode forfra.

Med max children reached er procesmanageren afgørende: Eksempelkonfigurationen for PHP 8.4.21 beskriver tælleren for »dynamic« og »ondemand«. Ved »static« må du ikke betragte en værdi på nul som tegn på ledig kapacitet. For slow requests Tærsklen og Slowlog skal være konfigureret korrekt; tærsklen bestemmer, hvilke lange forespørgsler der overhovedet registreres.

Sammenlign udskriftsformater og procesdetaljer

Den korte udgave er velegnet til at få et overblik over hele puljen. Valget af format afhænger af, om du vil aflæse værdierne manuelt eller regelmæssigt behandle dem via et overvågningssystem. Parameteren full udvider udskriften med procesdetaljer; det er ikke et selvstændigt udvekslingsformat.

PHP-håndbogen indeholder desuden dokumentation om XML og HTML. Ved automatiserede hentninger bør du kontrollere, hvilken FPM-version der rent faktisk er installeret, samt dens output, før du baserer dig på bestemte felter eller procesdetaljer. Især bør du være opmærksom på kombinationen af OpenMetrics og full at kontrollere det i sin egen version i stedet for generelt at antage, at der foreligger data for de enkelte processer.

Die Anmodning om varighed I Full-udgaven angives værdien i mikrosekunder. For en aktiv proces angiver den varigheden af den forespørgsel, der netop behandles; for en inaktiv proces henviser den til den senest behandlede forespørgsel. En høj værdi for en ledig worker betyder derfor ikke, at denne stadig er i gang med at behandle forespørgslen.

Felterne last request cpu og last request memory vises som nul for processer, der er i gang, fordi de først evalueres, når forespørgslen er afsluttet. Disse nulværdier indikerer derfor ikke et manglende CPU- eller hukommelsesforbrug. Gentagne forespørgsler kan vise, om en proces forbliver i gang i længere tid, men de kan ikke erstatte en fuldstændig applikationssporing.

Undersøgelse af køer og langsomme forespørgsler

Hvis den kø Hvis dette gentager sig, mens mange processer er aktive og kun få er ledige, er en overbelastet pool en plausibel arbejdshypotese. Et enkelt tjek er ikke nok: Sammenlign flere tidspunkter, og vær opmærksom på, om svartiderne for forespørgsler stiger samtidig. Køens maksimale værdi alene siger ikke noget om, hvorvidt der stadig er forespørgsler, der venter.

Sammenlign tidsperioden med FPM-logfiler, CPU-udnyttelse og ledig hukommelse. Medtag også databasen, cachen og eksterne tjenester: Hvis PHP venter på en langsom afhængighed, forbliver workerne beskæftigede, selvom ekstra CPU-kapacitet i sig selv ikke nødvendigvis løser problemet. Statussiden viser belastningen, men angiver ikke pålideligt årsagen hertil.

Hent den beskyttede fuldudgave gentagne gange under en fase, hvor der er usædvanlig aktivitet. En lang anmodningsvarighed for den samme aktive proces kan tyde på en worker, der har været beskæftiget i længere tid; kontroller i den forbindelse processtatus, da varigheden for en inaktiv proces refererer til dens sidste anmodning. PID, URI og script hjælper med at identificere processen, men giver ikke et fuldstændigt spor.

Især i forbindelse med en front-controller kan det samme scriptnavn dække mange forskellige applikationsfunktioner. Suppler derfor observationen med applikationssporing og en passende konfigureret Slowlog. Dens tærskelværdi bestemmer, hvilke lange forespørgsler der registreres; en manglende angivelse beviser ikke, at alle forespørgsler var hurtige. Hvordan du kan analysere udskrifterne mere indgående, fremgår af indlægget om Analyse af PHP-FPM-slowloggen.

Notér tidsvinduet og den berørte pool til sammenligningen. På den måde kan du f.eks. kontrollere, om en langsom databaseforespørgsel tidsmæssigt passer med de optagede arbejdere, eller om køen allerede var vokset inden da. En sammenhæng indsnævrer søgningen, men erstatter endnu ikke kontrollen af den konkrete anmodning.

Overvågning og nedbrud på statussiden

Ved tilbagevendende belastningsspidser giver regelmæssige, beskyttede hentninger et mere pålideligt billede end lejlighedsvise enkeltmålinger. JSON egner sig til automatiseret behandling; OpenMetrics er et alternativ, hvis den installerede PHP-version og overvågningsklienten er kompatible. Gem tidspunktet og poolens identitet for hvert målepunkt, så du ikke ved en fejltagelse sammenligner forskellige pools.

Behandl manglende hentninger som separate hændelser og ikke som nulværdier. Et hul kan skyldes netværket, adgangsbeskyttelsen eller statustjenesten; det indikerer i sig selv hverken en tom pulje eller et programnedbrud. Gem derfor også fejl og tidsoverskridelser ved hentningen, så hullet forbliver synligt ved den senere analyse.

Vær desuden opmærksom på nulstilling af akkumulerede tællere efter en FPM-genstart. En negativ forskel mellem to værdier er ikke en negativ forbindelseshastighed; start beregningen forfra efter nulstillingen, og tag højde for det afbrudte interval. Starttidspunktet og pool-tildelingen hjælper også med at placere et sådant brud i forløbet.

Hvis statusforespørgslen kører gennem samme pool som applikationen, kan den selv vente, hvis der ikke er flere arbejdere til rådighed. Til denne situation tilbyder pm.status_listen en separat FastCGI-lytter med en uafhængigt fungerende intern pool. Den kan muliggøre statusdiagnose, mens hovedpoolen er optaget; den øger dog ikke dens behandlingskapacitet.

Den ekstra listener kræver en udtrykkeligt tildelt, beskyttet webserver-routing. Sikr også dens FastCGI-adgang, og kontroller efter en godkendt ændring, om hentningen faktisk leverer den ønskede poolstatus. På den måde forbliver diagnosen adskilt fra den normale applikationssti, uden at statusdataene gøres offentligt tilgængelige.

Gennemgå resultaterne og vælge foranstaltninger

En FPM-ping og statussiden giver svar på forskellige spørgsmål. Pingen viser, om FPM svarer på den pågældende forespørgsel; den giver ikke tilsvarende oplysninger om ledige workere eller ventende forespørgsler. En vellykket ping er derfor i sig selv ikke en garanti for, at applikationspuljen ikke er overbelastet.

Hvis procesværdierne ikke stemmer overens med logfiler eller andre observationer, skal du først kontrollere pool-tildelingen, hentetidspunktet og overveje en eventuel genstart. Sammenlign derefter værdierne med andre tilgængelige proces- og driftsdata. Behandl afvigelsen i første omgang som et uafklaret fund, i stedet for straks at udlede en årsag eller en nødvendig konfigurationsændring heraf.

Hvis gentagne »Full«-hentninger og Slowlog-poster viser de samme lange anmodningsmønstre, skal du først undersøge de berørte applikationsstier. Ligger forsinkelsen derimod i en database eller en ekstern tjeneste, kan en analyse heraf have større effekt end en ændring af antallet af arbejdere. Det afgørende er, om foranstaltningen løser den observerede årsag og ikke blot et enkelt symptom.

En tilpasning af pm.max_children kan overvejes, hvis det kan påvises, at puljen arbejder på sin grænse, og at CPU, hukommelse samt efterfølgende tjenester kan håndtere yderligere parallelitet. Flere arbejdsprocesser kræver ressourcer og kan øge presset på disse tjenester. Der findes derfor ikke et universelt gyldigt tal; procesmanagerens driftsform indgår i vurderingen.

Efter at en ændring er blevet implementeret, skal du sammenligne den samme pool igen under så sammenlignelige belastningsforhold som muligt: Kø, svartider, fejl og ressourceforbrug hænger sammen. Notér også, hvis en foranstaltning ikke medfører nogen forbedring eller øger belastningen på en afhængighed. Først dette Før-og-efter-sammenligning gør det muligt at træffe en velbegrundet beslutning om, hvordan man skal gå videre.