Utilizzo della pagina di stato di PHP-FPM per l'analisi delle prestazioni

Cosa mostra la pagina di stato relativa al pool

La pagina di stato di PHP-FPM mostra come un determinato piscina Richieste PHP elaborate: tra le altre cose, quanti processi sono attivi o liberi e se ci sono richieste in attesa. Il presupposto è che l’applicazione sia effettivamente gestita da PHP-FPM. La versione di PHP visualizzata dalla riga di comando, di per sé, non indica né questo né la versione del servizio FPM responsabile.

Pertanto, individua innanzitutto la versione di FPM in uso e il pool a cui il server web inoltra l’applicazione. Ciò include il socket Unix o il listener TCP utilizzato e il routing nell'host virtuale di competenza. Questa associazione è importante affinché una successiva interrogazione dello stato non si riferisca accidentalmente a un altro pool.

Se un server gestisce più pool, i dati visualizzati si riferiscono al pool specificato nella richiesta e non valgono automaticamente per tutte le applicazioni PHP. Nell’hosting condiviso potresti non disporre dei diritti necessari per la configurazione del pool o del server web. In tal caso, dovrai affidarti al fatto che il provider metta a disposizione la pagina di stato o indicatori simili in modo protetto.

Una richiesta è innanzitutto una Istantanea: Tra due richieste possono formarsi brevi code che poi scompaiono. Altri valori contano gli eventi a partire dall'avvio dell'FPM; in caso di riavvio, vengono azzerati. Per ottenere una cronologia significativa, è quindi consigliabile salvare l'ora della richiesta e l'identità del pool insieme ai valori.

Questa pagina non spiega l'intero tempo di attesa nel browser. Anche la rete, il server web, il database e i servizi esterni possono influire sul tempo di risposta. Si tratta quindi di un punto di partenza per la diagnosi del pool PHP-FPM, non di un test completo delle prestazioni del sito web.

Comprendere i worker e i gestori di processo

Il gestore dei processi determina in che modo il pool assegna i propri worker. In caso di static il loro numero rimane costante. dynamic adegua il numero alle esigenze, entro i limiti configurati; ondemand avvia i processi quando necessario. La capacità disponibile prevista dipende quindi anche dalla modalità operativa impostata.

Un processo attivo sta elaborando una richiesta; un processo libero è pronto a lavorare. La presenza di molti worker attivi non è automaticamente indice di un errore: un pool a pieno regime può elaborare rapidamente le richieste. L’osservazione diventa più significativa quando, contemporaneamente, ci sono richieste in attesa, i tempi di risposta aumentano e i processi liberi disponibili sono pochissimi.

Anche una riserva temporaneamente esaurita non costituisce di per sé una prova di una carenza persistente. Confronta i prelievi ripetuti con quanto configurato Limite di processo e gli orari in cui gli utenti rilevano effettivamente dei rallentamenti. In questo modo è più facile distinguere un breve picco di carico da un sovraccarico ricorrente.

Un numero maggiore di worker può elaborare più richieste in parallelo, ma richiede memoria aggiuntiva e può gravare maggiormente sui database o sui servizi esterni. Se molti processi sono in attesa della stessa dipendenza lenta, aumentare il limite non risolve il problema alla radice. Verifica quindi le risorse e la durata delle richieste prima di pm.max_children cambiamento.

Per definire le competenze all’interno dello stack di hosting, è utile il confronto tra NGINX Unit e PHP-FPM. Esso integra la prospettiva architettonica; dovrai comunque verificare i valori di stato effettivi e le impostazioni del Process Manager nel pool FPM effettivamente in uso.

Proteggere l'accesso allo stato e FastCGI

I dati di stato possono rivelare informazioni sensibili relative alle richieste e alle risorse. In particolare, i dettagli dei processi possono contenere URI di richiesta che consentono di risalire alle funzioni richiamate o ai parametri trasmessi. Tratta quindi la pagina come un accesso diagnostico e non come un pannello di controllo pubblico dello stato.

Limita il Accesso HTTP in risposta a richieste interne o a indirizzi IP dei client espressamente indicati. Verifica quale indirizzo il server web rilevi effettivamente come client nel caso in cui sia presente un proxy a monte. La protezione deve essere applicata all’instradamento della pagina di stato e dovrebbe essere verificata prima della pubblicazione.

Assicurati comunque il Accesso FastCGI da soli. Nel caso di un socket Unix, sono rilevanti il proprietario e i permessi; nel caso del protocollo TCP, occorre verificare l’associazione di rete e i client autorizzati. Un blocco nel server web non protegge una porta FastCGI accessibile separatamente da una rete non affidabile.

Il progetto PHP ha documentato, con il codice CVE-2026-6735, una vulnerabilità XSS nell'output di stato di FPM. Le versioni corrette includono PHP 8.4.21 e 8.5.6. Per altri rami di versione e pacchetti di distribuzione, verifica il rispettivo stato di sicurezza o le patch retroportate, invece di dedurre la protezione basandoti esclusivamente sul numero di versione visualizzato.

Un aggiornamento non sostituisce la limitazione dell'accesso: anche una pagina di stato corretta può continuare a rivelare dettagli operativi. Mantieni sia l'accesso HTTP che il listener limitati alla cerchia di utenti prevista e tieni conto di questi due livelli di protezione in caso di successive modifiche al routing.

Pubblicare la pagina di stato in modalità protetta

Per prima cosa, individua quale pool FPM gestisce l’applicazione in questione e tramite quale socket o indirizzo TCP il server web vi accede. In presenza di più pool, la richiesta di stato viene indirizzata al pool a cui viene inoltrata. La versione PHP visualizzata dalla riga di comando non indica di per sé quale servizio FPM sia responsabile dell’applicazione.

Nel file di configurazione del pool in questione, il seguente frammento attiva il Percorso di stato. Non si tratta di un file PHP che devi creare nella cartella dei documenti. L'estratto è un suggerimento di configurazione e presuppone che tu abbia i permessi per modificare la configurazione del pool.

pm.status_path = /fpm-status

Configura nel server web una route adeguata che inoltri le richieste a questo percorso direttamente tramite FastCGI al pool individuato. Il normale routing dell’applicazione non deve intercettare la richiesta. Limita l'accesso HTTP alle richieste interne o agli indirizzi IP dei client conosciuti e proteggi il socket FastCGI indipendentemente da ciò tramite autorizzazioni, restrizioni di rete e client autorizzati.

Prima del rollout definitivo, verifica sia la configurazione del server web che quella di FPM utilizzando le procedure di controllo previste nel tuo ambiente. Assicurati di modificare il servizio e il pool corretti e che la restrizione di accesso sia applicata anche al percorso di stato. Il semplice fatto di impostare un percorso non rende ancora l’output accessibile tramite HTTP.

Per un ambiente già configurato e protetto localmente, il seguente comando da terminale legge l'output JSON. Presuppone che all'indirizzo specificato sia raggiungibile un host virtuale HTTP locale corrispondente. In caso contrario, dovrai adattare l'indirizzo, il routing dell'host e, se necessario, il TLS al tuo ambiente; il comando non modifica alcuna configurazione.

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

Nella risposta, controlla in particolare il nome del pool. Un messaggio di errore o un output imprevisto dell'applicazione può indicare un routing errato; anche un blocco dell'accesso può impedire il recupero dei dati. Verifica quindi la configurazione del server web interessato e i log, invece di rimuovere la protezione in modo affrettato.

Come interpretare e calcolare correttamente gli indicatori chiave

I valori di stato descrivono periodi di tempo diversi: alcuni indicano lo stato al momento della lettura, altri contano gli eventi o registrano un valore massimo dall’avvio. Ai fini della diagnosi, questa distinzione è più importante di un singolo valore anomalo. La tabella seguente classifica i dati principali.

Per un Velocità di connessionesottrai due valori da accepted conn dall’uno all’altro e dividi la differenza per il tempo trascorso. Esempio di calcolo ipotetico, non basato su misurazioni: se il contatore passa da 12.000 a 12.600 in 60 secondi, si ottiene una media di dieci connessioni ipotetiche al secondo. Da questo dato non è possibile dedurre direttamente né le visualizzazioni delle pagine né la latenza dell’applicazione.

Salva l'ora e l'identità del pool per ogni punto di misurazione. Dopo un riavvio dell'FPM, i valori di stato vengono azzerati; una differenza che va oltre questa interruzione non costituisce quindi una frequenza valida. Rileva un contatore azzerato o un orario di inizio modificato e ricomincia il calcolo per il nuovo periodo.

All'indirizzo max children reached il gestore dei processi è fondamentale: la configurazione di esempio di PHP 8.4.21 descrive il contatore per “dynamic” e “ondemand”. Nel caso di “static”, non devi interpretare un valore pari a zero come prova di capacità disponibile. Per slow requests È necessario configurare correttamente la soglia e lo slowlog; la soglia determina quali richieste lunghe vengono effettivamente registrate.

Confronta i formati di output e i dettagli del processo

La versione breve è ideale per avere una panoramica dell'intero pool. La scelta del formato dipende dal fatto che tu voglia leggere i valori manualmente o elaborarli regolarmente tramite un sistema di monitoraggio. Il parametro full aggiunge all'output i dettagli del processo; non è un formato di scambio autonomo.

Il manuale di PHP documenta inoltre XML e HTML. In caso di richiami automatici, verifica la versione di FPM effettivamente installata e i suoi output prima di fare affidamento su campi specifici o dettagli del processo. In particolare, dovresti considerare la combinazione di OpenMetrics e full verificare nella propria versione, invece di dare per scontati in modo generalizzato i dati dei singoli processi.

Il sito Durata della richiesta Nella versione completa il valore è espresso in microsecondi. Nel caso di un processo attivo, indica la durata della richiesta attualmente in elaborazione; nel caso di un processo inattivo, si riferisce all'ultima richiesta elaborata. Un valore elevato per un worker libero non significa quindi che questi sia ancora impegnato con la richiesta.

I campi last request cpu e last request memory nei processi attivi vengono restituiti come zero, poiché la loro valutazione avviene solo al termine della richiesta. Questi valori pari a zero non indicano quindi un consumo mancante di CPU o memoria. Richieste ripetute possono mostrare se un processo rimane attivo più a lungo; tuttavia, non sostituiscono un tracciamento completo dell'applicazione.

Analizzare le code e le richieste lente

Se il coda Se la situazione si ripete, con molti processi attivi e pochi liberi, un pool sovraccarico è un’ipotesi plausibile. Un singolo controllo non è sufficiente: confronta diversi momenti e verifica se, contemporaneamente, aumentano i tempi di risposta alle richieste. Il valore massimo della coda, di per sé, non indica se ci siano ancora richieste in attesa.

Confronta il periodo in questione con i log FPM, il carico della CPU e la memoria disponibile. Prendi in considerazione anche il database, la cache e i servizi esterni: se PHP è in attesa di una dipendenza lenta, i worker rimangono occupati, anche se una maggiore potenza della CPU da sola non risolve necessariamente il problema. La pagina di stato mostra l’occupazione, ma non ne indica in modo affidabile la causa.

Richiedi ripetutamente l'output completo protetto durante una fase anomala. Una durata prolungata della richiesta per lo stesso processo attivo può indicare un worker occupato da tempo; in tal caso, verifica lo stato del processo, poiché nel caso di un processo inattivo la durata si riferisce alla sua ultima richiesta. PID, URI e script aiutano nell'identificazione, ma non forniscono una traccia completa.

Soprattutto nel caso di un front-controller, lo stesso nome di script può coprire molte funzioni diverse dell'applicazione. Completa quindi l'osservazione con il tracciamento dell'applicazione e un Slowlog. La sua soglia determina quali richieste lunghe vengono registrate; l’assenza di una voce non dimostra che tutte le richieste fossero veloci. Per capire come interpretare in modo approfondito i risultati, consulta l’articolo su Analisi dello slowlog di PHP-FPM.

Per l'analisi, registra la finestra temporale e il pool interessato. In questo modo potrai verificare, ad esempio, se una query lenta sul database coincide temporalmente con i worker occupati o se la coda si era già allungata in precedenza. Una correlazione restringe il campo di ricerca, ma non sostituisce ancora l'analisi della richiesta specifica.

Monitoraggio e interruzioni della pagina di stato

In caso di picchi di carico ricorrenti, le letture regolari e protette sono più significative rispetto a singoli controlli occasionali. JSON è adatto all’elaborazione automatizzata; OpenMetrics rappresenta un’alternativa se la versione di PHP installata e il client di monitoraggio sono compatibili. Salva per ogni punto di misurazione l'ora e l'identità del pool, in modo da non confrontare inavvertitamente pool diversi.

Trattare richieste mancanti come eventi a sé stanti e non come valori nulli. Una lacuna può essere dovuta alla rete, alla protezione degli accessi o al servizio di stato; di per sé non indica né un pool vuoto né un’interruzione dell’applicazione. Conserva quindi anche gli errori e i timeout delle richieste, in modo che la lacuna rimanga visibile nella successiva analisi.

Tieni inoltre conto del ripristino dei contatori cumulativi dopo un riavvio dell’FPM. Una differenza negativa tra due valori non indica una velocità di connessione negativa; ricomincia il calcolo dopo il ripristino e tieni conto dell'intervallo interrotto. Anche l'ora di inizio e l'assegnazione al pool aiutano a contestualizzare tale interruzione nell'andamento.

Se la richiesta di stato viene eseguita dallo stesso pool dell'applicazione, può attendere autonomamente nel caso in cui i worker siano esauriti. Per questa situazione, pm.status_listen un listener FastCGI separato con un pool interno che opera in modo indipendente. Esso può consentire la diagnosi dello stato mentre il pool principale è occupato; tuttavia, non ne aumenta la capacità di elaborazione.

Il listener aggiuntivo richiede un routing del server web protetto e assegnato in modo esplicito. Proteggi anche il suo accesso FastCGI e, dopo aver apportato una modifica approvata, verifica se la richiesta restituisce effettivamente lo stato del pool desiderato. In questo modo, la diagnosi rimane separata dal normale percorso dell'applicazione, senza rendere pubblici i dati di stato.

Verificare i risultati e scegliere le misure da adottare

Un ping FPM e la pagina di stato forniscono risposte a domande diverse. Il ping indica se FPM risponde alla richiesta in questione; non fornisce però informazioni equivalenti sui worker liberi o sulle richieste in attesa. Un ping andato a buon fine, di per sé, non è quindi un segnale di rassicurazione riguardo al carico del pool di applicazioni.

Se i dati di processo non corrispondono ai log o ad altre osservazioni, verifica innanzitutto l'assegnazione al pool, l'ora di richiamo e la possibilità di un riavvio. Confronta quindi i valori con ulteriori dati di processo e di funzionamento disponibili. Considera inizialmente la discrepanza come un dato in sospeso, invece di dedurne immediatamente una causa o una modifica necessaria alla configurazione.

Se le richieste "Full" ripetute e le voci dello slowlog mostrano gli stessi schemi di richiesta prolungati, esamina innanzitutto i percorsi applicativi interessati. Se invece il ritardo è dovuto a un database o a un servizio esterno, la loro analisi può rivelarsi più efficace rispetto a una modifica del numero di worker. È fondamentale che l’intervento affronti la causa osservata, non solo un singolo sintomo.

Un adeguamento di pm.max_children È una soluzione da prendere in considerazione se si può dimostrare che il pool sta operando al limite delle proprie capacità e che la CPU, la memoria e i servizi a valle sono in grado di gestire un ulteriore livello di parallelismo. Un numero maggiore di worker richiede risorse aggiuntive e può aumentare la pressione su tali servizi. Non esiste quindi un numero valido in tutti i casi; nella valutazione occorre tenere conto della modalità operativa del gestore dei processi.

Dopo aver implementato una modifica, confronta nuovamente lo stesso pool in condizioni di carico il più possibile simili: coda, tempi di risposta, errori e consumo di risorse vanno considerati nel loro insieme. Prendi nota anche dei casi in cui un intervento non apporta alcun miglioramento o aggrava il carico su una dipendenza. Solo questo Confronto prima-dopo consente di prendere una decisione motivata su come procedere.