Använda PHP-FPM:s statussida för prestandaanalys

Vad statussidan visar om poolen

PHP-FPM-statussidan visar hur en viss pool Bearbetade PHP-förfrågningar: bland annat hur många processer som är aktiva eller lediga och om det finns förfrågningar som väntar. Förutsättningen är att applikationen faktiskt hanteras av PHP-FPM. Den PHP-version som visas via kommandoraden anger varken detta eller versionen av den ansvariga FPM-tjänsten.

Ta därför först reda på vilken FPM-version som används och vilken pool som webbservern vidarebefordrar applikationen till. Detta omfattar den använda Unix-socketen eller TCP-lyssnaren samt routningen i den berörda virtuella värden. Denna tilldelning är viktig för att en senare statusförfrågan inte av misstag ska avse en annan pool.

Om en server kör flera pooler gäller resultatet endast för den pool som förfrågan avser och inte automatiskt för alla PHP-applikationer. Vid delad hosting kan det hända att du saknar behörighet att konfigurera poolen eller webbservern. I så fall är du beroende av att leverantören tillhandahåller statussidan eller motsvarande nyckeltal på ett skyddat sätt.

En hämtning är i första hand en Ögonblicksbild: Korta köer kan uppstå mellan två förfrågningar och sedan försvinna igen. Andra värden räknar händelser sedan FPM startades; vid en omstart nollställs de. För att få en meningsfull tidsserie bör du därför spara hämtningstid och poolidentitet tillsammans med värdena.

Sidan förklarar inte hela väntetiden i webbläsaren. Nätverket, webbservern, databasen och externa tjänster kan också påverka svarstiden. Den utgör därför en utgångspunkt för felsökning av PHP-FPM-poolen, inte ett fullständigt prestandatest av webbplatsen.

Att förstå arbetare och processledare

Processhanteraren avgör hur poolen tilldelar sina arbetare. Vid static förblir antalet oförändrat. dynamic anpassar antalet efter behovet inom de konfigurerade gränserna; ondemand startar processer vid behov. Vilken ledig kapacitet du kan förvänta dig beror alltså också på vilken driftsläge som är inställt.

En aktiv process bearbetar just nu en förfrågan; en ledig process står redo att ta emot arbete. Att det finns många aktiva arbetare är inte nödvändigtvis ett tecken på ett fel: en fullt utnyttjad pool kan hantera förfrågningar snabbt. Observationen blir mer betydelsefull om det samtidigt finns förfrågningar som väntar, svarstiderna ökar och det knappt finns några lediga processer tillgängliga.

Även en tillfälligt tom reserv är i sig inte något bevis på en varaktig brist. Jämför upprepade uttag med den konfigurerade Processgräns och de tidpunkter då användarna faktiskt märker fördröjningar. På så sätt kan du bättre skilja en kort belastningstop från en återkommande överbelastning.

Fler arbetare kan hantera fler förfrågningar parallellt, men kräver mer minne och kan belasta databaser eller externa tjänster i högre grad. Om många processer väntar på samma långsamma beroende, löser en högre gräns inte orsaken. Kontrollera därför resurserna och förfrågningens varaktighet innan du pm.max_children förändring.

För att kartlägga ansvarsfördelningen inom hosting-stacken kan det vara till hjälp att jämföra NGINX Unit och PHP-FPM. Det kompletterar arkitekturperspektivet; de faktiska statusvärdena och inställningarna för processhanteraren måste du fortfarande kontrollera i den FPM-pool som faktiskt används.

Säkra åtkomst till status och FastCGI

Statusinformationen kan avslöja känslig information om förfrågningar och resurser. I synnerhet kan processdetaljer innehålla förfrågnings-URI:er som gör det möjligt att dra slutsatser om vilka funktioner som anropats eller vilka parametrar som skickats. Behandla därför sidan som en diagnostisk åtkomstpunkt och inte som en offentlig statusöversikt.

Begränsa HTTP-åtkomst vid interna förfrågningar eller uttryckligen angivna klient-IP-adresser. Kontrollera då vilken adress webbservern faktiskt ser som klient om en proxy är kopplad före den. Skyddet måste gälla för vidarebefordran av statussidan och bör kontrolleras innan den släpps.

Se till att säkra FastCGI-åtkomst själv. För en Unix-sockel är ägare och behörigheter avgörande; för TCP måste nätverksbindningen och godkända klienter kontrolleras. En spärr på webbservern skyddar inte en FastCGI-port som är separat tillgänglig från ett opålitligt nätverk.

PHP-projektet dokumenterar en XSS-sårbarhet i FPM:s statusutmatning med referensen CVE-2026-6735. Korrigerade versioner inkluderar PHP 8.4.21 och 8.5.6. Kontrollera säkerhetsstatusen eller de bakåtportade korrigeringarna för andra versionsgrenar och distributionspaket, istället för att enbart utgå från det visade versionsnumret för att dra slutsatser om säkerheten.

En uppdatering ersätter inte åtkomstbegränsningen: Även en korrigerad statussida kan fortfarande avslöja driftsrelaterade detaljer. Se till att både HTTP-åtkomsten och lyssnaren begränsas till den avsedda användargruppen och ta hänsyn till dessa två skyddslager vid senare ändringar av routningen.

Publicera statussidan som skyddad

Ta först reda på vilken FPM-pool som hanterar den aktuella applikationen och via vilken socket eller TCP-adress webbservern når den. Om det finns flera pooler hör statusförfrågan till den pool som den vidarebefordras till. PHP-versionen som visas i kommandoraden visar inte i sig vilken FPM-tjänst som ansvarar för applikationen.

I konfigurationsfilen för den berörda poolen aktiverar följande utdrag Statusväg. Det är ingen PHP-fil som du måste skapa i dokumentkatalogen. Utdraget är ett konfigurationsförslag och förutsätter att du har behörighet att redigera poolkonfigurationen.

pm.status_path = /fpm-status

Konfigurera en lämplig rutt på webbservern som vidarebefordrar förfrågningar till denna sökväg direkt via FastCGI till den identifierade poolen. Den vanliga applikationsruttningen får inte avlyssna förfrågan. Begränsa HTTP-åtkomsten till interna förfrågningar eller kända klient-IP-adresser och säkra FastCGI-socketen oberoende av detta genom behörigheter respektive nätverksbindning och godkända klienter.

Kontrollera både webbserver- och FPM-konfigurationen med de testmetoder som används i din miljö innan den godkända utrullningen. Se till att du ändrar rätt tjänst och pool och att åtkomstbegränsningen även gäller för statusvägen. Enbart en inställd sökväg gör inte utdata tillgänglig via HTTP.

För en redan konfigurerad, lokalt skyddad miljö läser följande terminalkommando in JSON-utdata. Det förutsätter att en lämplig lokal virtuell HTTP-värd är tillgänglig på den angivna adressen. I annat fall måste du anpassa adressen, värd-routing och, om nödvändigt, TLS till din miljö; hämtningen ändrar inte någon konfiguration.

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

Kontrollera särskilt poolnamnet i svaret. Ett felmeddelande eller oväntad utdata från applikationen kan tyda på felaktig routning; även en åtkomstspärr kan förhindra hämtningen. Kontrollera då den berörda webbserverns konfiguration och loggarna, istället för att förhastat ta bort skyddet.

Att tolka och beräkna nyckeltal på rätt sätt

Statusvärdena beskriver olika tidsperioder: Vissa visar tillståndet vid avläsningen, andra räknar händelser eller registrerar ett högsta värde sedan starten. För en diagnos är denna distinktion viktigare än ett enskilt avvikande värde. I följande tabell redovisas de viktigaste uppgifterna.

För en Anslutningshastighetsubtraherar du två värden från accepted conn från varandra och delar skillnaden med den förflutna tiden. Hypotetiskt räkneexempel, ingen mätning: Om räknaren stiger från 12 000 till 12 600 inom 60 sekunder blir det i genomsnitt tio antagna anslutningar per sekund. Av detta kan varken sidvisningar eller applikationslatens direkt härledas.

Spara tid och poolidentitet för varje mätpunkt. Efter en omstart av FPM återställs statusvärdena; en skillnad över denna brytpunkt är därför inte en giltig hastighet. Upptäck en minskad räknare eller en ändrad starttidpunkt och börja om beräkningen för den nya tidsperioden.

Med max children reached är processhanteraren avgörande: Exempelkonfigurationen för PHP 8.4.21 beskriver räknaren för ”dynamic” och ”ondemand”. Vid ”static” får du inte tolka ett nollvärde som ett tecken på ledig kapacitet. För slow requests Tröskelvärdet och Slowlog måste vara korrekt inställda; tröskelvärdet avgör vilka långa förfrågningar som överhuvudtaget registreras.

Jämföra utskriftsformat och processdetaljer

Den korta versionen är lämplig för att få en överblick över hela poolen. Valet av format beror på om du vill avläsa värdena manuellt eller regelbundet bearbeta dem via ett övervakningssystem. Parametern full utökar utdata med processdetaljer; det är inte ett fristående utbytesformat.

PHP-handboken beskriver dessutom XML och HTML. Vid automatiserade hämtningar bör du kontrollera vilken FPM-version som faktiskt är installerad och dess utdata innan du förlitar dig på specifika fält eller processdetaljer. I synnerhet bör du beakta kombinationen av OpenMetrics och full kontrollera i sin egen version, istället för att generellt utgå från enskilda processdata.

Die Förfrågans varaktighet I Full-utgåvan anges värdet i mikrosekunder. För en aktiv process anger det varaktigheten för den förfrågan som just nu bearbetas; för en inaktiv process avser det den senast bearbetade förfrågan. Ett högt värde för en ledig arbetare innebär därför inte att denne just nu fortfarande är upptagen med förfrågan.

Fälten last request cpu och last request memory visas som noll för aktiva processer, eftersom utvärderingen sker först efter att förfrågan har slutförts. Dessa nollvärden indikerar alltså inte någon brist på CPU- eller minnesanvändning. Upprepade avläsningar kan visa om en process förblir aktiv under en längre tid, men de ersätter inte en fullständig spårning av applikationen.

Undersöka köer och långsamma förfrågningar

Om kö Om detta upprepas, samtidigt som många processer är aktiva och endast ett fåtal är lediga, är en överbelastad pool en rimlig arbetshypotes. En enskild avläsning räcker inte för detta: Jämför flera tidpunkter och se efter om svarstiderna för förfrågningar ökar samtidigt. Köens högsta värde i sig säger inte om det fortfarande finns förfrågningar som väntar.

Jämför tidsperioden med FPM-loggar, CPU-utnyttjande och tillgängligt minne. Ta även hänsyn till databasen, cachen och externa tjänster: Om PHP väntar på en långsam beroendekomponent förblir arbetarna sysselsatta, även om ytterligare CPU-kapacitet i sig inte nödvändigtvis löser problemet. Statussidan visar belastningen, men inte alltid orsaken till den på ett tillförlitligt sätt.

Hämta den skyddade fullständiga utgåvan upprepade gånger under en period då den är synlig. En lång begärandetid för samma aktiva process kan tyda på en arbetare som varit sysselsatt under en längre tid; kontrollera då processens status, eftersom tiden för en inaktiv process avser dess senaste begäran. PID, URI och skript hjälper till med tilldelningen, men ger inte en fullständig spårning.

Särskilt när det gäller en front-controller kan samma skriptnamn täcka många olika applikationsfunktioner. Komplettera därför observationen med applikationsspårning och en lämpligt konfigurerad Slowlog. Tröskelvärdet avgör vilka långa förfrågningar som registreras; att det saknas en post innebär inte att alla förfrågningar var snabba. Hur du kan analysera utdata mer ingående beskrivs i inlägget om Analys av PHP-FPM-slowloggen.

Notera tidsfönstret och den berörda poolen för jämförelsen. På så sätt kan du till exempel kontrollera om en långsam databasförfrågan tidsmässigt stämmer överens med de upptagna arbetarna eller om köen redan hade börjat växa tidigare. En korrelation begränsar sökningen, men ersätter ännu inte granskningen av den specifika förfrågan.

Övervakning och driftstörningar på statussidan

Vid återkommande belastningstoppar ger regelbundna, skyddade avläsningar mer meningsfulla resultat än sporadiska enskilda kontroller. JSON lämpar sig för automatiserad bearbetning; OpenMetrics är ett alternativ om den installerade PHP-versionen och övervakningsklienten är kompatibla. Spara tidpunkten och poolens identitet för varje mätpunkt, så att du inte av misstag jämför olika pooler.

Behandla uteblivna hämtningar som separata händelser och inte som nollvärden. En lucka kan bero på nätverket, åtkomstskyddet eller statustjänsten; den innebär i sig varken en tom pool eller ett applikationsavbrott. Spara därför även fel och tidsöverskridanden vid hämtningen, så att luckan förblir synlig vid en senare utvärdering.

Beakta dessutom att ackumulerade räknare nollställs efter en omstart av FPM. En negativ skillnad mellan två värden innebär inte en negativ anslutningshastighet; börja om beräkningen efter återställningen och ta hänsyn till det avbrutna intervallet. Även starttid och pooltilldelning hjälper till att placera ett sådant avbrott i tidsförloppet.

Om statusförfrågan körs via samma pool som applikationen kan den vänta på egen hand om arbetarna är upptagna. För denna situation erbjuder pm.status_listen en separat FastCGI-lyssnare med en självständigt fungerande intern pool. Den kan möjliggöra statusdiagnostik medan huvudpoolen är upptagen, men ökar inte dess bearbetningskapacitet.

Den extra lyssnaren kräver en uttryckligen tilldelad, skyddad webbserverrouting. Säkra även dess FastCGI-åtkomst och kontrollera efter en godkänd ändring om hämtningen faktiskt ger den önskade poolstatusen. På så sätt hålls diagnostiken åtskild från den normala applikationsvägen, utan att statusdata görs allmänt tillgängliga.

Granska resultaten och välja åtgärder

En FPM-ping och statussidan ger svar på olika frågor. Pingen visar om FPM svarar på den aktuella förfrågan; den ger ingen motsvarande information om lediga arbetare eller väntande förfrågningar. En lyckad ping i sig är därför inte någon garanti för att belastningen på applikationspoolen är under kontroll.

Om processvärdena inte stämmer överens med loggarna eller andra observationer, kontrollera först pooltilldelningen, hämtningstidpunkten och om en omstart kan behövas. Jämför därefter värdena med ytterligare tillgängliga process- och driftsdata. Behandla avvikelsen inledningsvis som ett öppet fynd, istället för att omedelbart dra slutsatser om en orsak eller en nödvändig konfigurationsändring.

Om upprepade full-hämtningar och slowlog-poster visar samma långa förfrågningsmönster, bör du först undersöka de berörda applikationsvägarna. Om fördröjningen däremot beror på en databas eller en extern tjänst kan en analys av dessa ge bättre resultat än att ändra antalet arbetare. Det avgörande är om åtgärden åtgärdar den observerade orsaken, inte bara ett enskilt symptom.

En anpassning av pm.max_children är ett alternativ om det kan bevisas att poolen arbetar på gränsen av sin kapacitet och att CPU, minne samt nedströms tjänster klarar av ytterligare parallellitet. Fler arbetare kräver resurser och kan öka belastningen på dessa tjänster. Det finns därför inget universellt giltigt antal; processhanterarens driftsläge ingår i bedömningen.

Jämför samma pool på nytt efter att en ändring har godkänts, under så likartade belastningsförhållanden som möjligt: kö, svarstider, fel och resursförbrukning hör ihop. Notera även om en åtgärd inte leder till någon förbättring eller om den ökar belastningen på ett beroende. Först detta Före-och-efter-jämförelse gör det möjligt att fatta ett välgrundat beslut om hur man ska gå vidare.