Utiliser la page d'état PHP-FPM pour analyser les performances

Ce que la page d'état indique au sujet du pool

La page d'état de PHP-FPM indique comment un certain piscine Requêtes PHP traitées : notamment le nombre de processus actifs ou disponibles, et s'il y a des requêtes en attente. Cela suppose que l'application soit effectivement gérée par PHP-FPM. La version de PHP affichée via la ligne de commande ne fournit à elle seule aucune indication à ce sujet, ni sur la version du service FPM concerné.

Commencez donc par déterminer la version de FPM utilisée et le pool vers lequel le serveur web redirige l'application. Cela inclut le socket Unix ou le listener TCP utilisé, ainsi que le routage dans l'hôte virtuel concerné. Cette association est importante pour éviter qu'une interrogation d'état ultérieure ne concerne par erreur un autre pool.

Si un serveur gère plusieurs pools, les informations affichées concernent uniquement le pool interrogé et ne s'appliquent pas automatiquement à toutes les applications PHP. En hébergement mutualisé, il se peut que vous ne disposiez pas des droits nécessaires pour configurer le pool ou le serveur web. Dans ce cas, vous devez compter sur le fournisseur pour qu'il mette à disposition la page d'état ou des indicateurs similaires sous forme sécurisée.

Une consultation est avant tout une Instantané: De courtes files d'attente peuvent apparaître et disparaître entre deux requêtes. D'autres valeurs comptabilisent les événements depuis le démarrage du FPM ; elles sont réinitialisées lors d'un redémarrage. Pour obtenir un historique significatif, enregistrez donc l'heure de la requête et l'identifiant du pool en même temps que les valeurs.

Cette page n'explique pas l'intégralité du temps d'attente dans le navigateur. Le réseau, le serveur web, la base de données et les services externes peuvent également influer sur le temps de réponse. Elle constitue donc un point de départ pour le diagnostic du pool PHP-FPM, et non un test de performance complet du site web.

Comprendre les « workers » et les gestionnaires de processus

Le gestionnaire de processus détermine la manière dont le pool met ses workers à disposition. Dans le cas de static leur nombre reste constant. dynamic adapte le nombre aux besoins, dans les limites configurées ; ondemand lance des processus en fonction des besoins. Les capacités disponibles auxquelles vous pouvez vous attendre dépendent donc également du mode de fonctionnement sélectionné.

Un processus actif traite actuellement une requête ; un processus libre est prêt à intervenir. La présence d'un grand nombre de processus actifs n'est pas nécessairement synonyme de problème : un pool à pleine capacité peut traiter les requêtes rapidement. Cette observation devient plus significative lorsque, parallèlement, des requêtes sont en attente, que les temps de réponse augmentent et qu'il n'y a pratiquement plus de processus libres disponibles.

Même une réserve temporairement vide ne constitue pas en soi une preuve d'un goulot d'étranglement durable. Comparez les appels répétés avec la configuration Limite de processus et les moments où les utilisateurs constatent effectivement des ralentissements. Cela te permet de distinguer plus facilement un bref pic de charge d'une surcharge récurrente.

Un plus grand nombre de workers permet de traiter davantage de requêtes en parallèle, mais nécessite davantage de mémoire et peut solliciter davantage les bases de données ou les services externes. Si de nombreux processus attendent la même dépendance lente, le fait d'augmenter la limite ne résout pas le problème à la source. Vérifie donc les ressources et la durée des requêtes avant de pm.max_children changer.

Pour déterminer la répartition des responsabilités au sein de la pile d'hébergement, il est utile de comparer NGINX Unit et PHP-FPM. Il complète la perspective architecturale ; tu dois toutefois continuer à vérifier les valeurs d'état concrètes et les paramètres du gestionnaire de processus au niveau du pool FPM effectivement utilisé.

Sécuriser l'accès aux statuts et FastCGI

Les informations d'état peuvent révéler des données sensibles concernant les requêtes et les ressources. Les détails des processus, en particulier, peuvent contenir des URI de requête permettant de déduire les fonctions appelées ou les paramètres transmis. Considérez donc cette page comme un accès de diagnostic et non comme un tableau de bord d'état public.

Limite le Accès HTTP aux requêtes internes ou aux adresses IP de clients expressément connues. Vérifie à cette occasion quelle adresse le serveur web identifie réellement comme provenant du client lorsqu'un proxy est intercalé. La protection doit s'appliquer au routage de la page d'état et doit être vérifiée avant toute mise en service.

Quoi qu'il en soit, assure-toi d'avoir le Accès FastCGI par vous-même. Pour un socket Unix, le propriétaire et les droits d'accès sont importants ; pour le protocole TCP, il faut vérifier la liaison réseau et les clients autorisés. Un verrouillage au niveau du serveur web ne protège pas un port FastCGI accessible séparément depuis un réseau non fiable.

Le projet PHP documente, sous la référence CVE-2026-6735, une vulnérabilité XSS dans la sortie d'état de FPM. Les versions corrigées comprennent PHP 8.4.21 et 8.5.6. Pour les autres branches de version et les paquets de distribution, vérifiez le niveau de sécurité correspondant ou les correctifs rétroportés, plutôt que de vous fier uniquement au numéro de version affiché pour déterminer si la protection est assurée.

Une mise à jour ne remplace pas la restriction d'accès : même une page d'état corrigée peut continuer à révéler des détails opérationnels. Limite l'accès HTTP ainsi que le listener au cercle d'utilisateurs prévu et tiens compte de ces deux niveaux de protection lors de modifications ultérieures du routage.

Mettre en ligne la page d'état en mode protégé

Commencez par déterminer quel pool FPM traite l'application en question et via quel socket ou quelle adresse TCP le serveur web y accède. S'il existe plusieurs pools, la requête d'état est attribuée au pool vers lequel elle est redirigée. La version PHP indiquée en ligne de commande ne permet pas à elle seule de déterminer quel service FPM est responsable de l'application.

Dans le fichier de configuration du pool concerné, l'extrait suivant active le Chemin d'accès. Il ne s'agit pas d'un fichier PHP que tu dois créer dans le répertoire des documents. Cet extrait est une proposition de configuration et suppose que tu sois autorisé à modifier la configuration du pool.

pm.status_path = /fpm-status

Configurez une route appropriée dans le serveur web afin que les requêtes adressées à ce chemin soient directement transmises au pool identifié via FastCGI. Le routage habituel des applications ne doit pas intercepter la requête. Limitez l'accès HTTP aux requêtes internes ou aux adresses IP de clients connus, et sécurisez le socket FastCGI indépendamment de cela, à l'aide d'autorisations, d'une liaison réseau et de clients autorisés.

Avant le déploiement officiel, vérifie la configuration du serveur Web et celle du FPM à l'aide des procédures de test prévues dans ton environnement. Assure-toi de modifier le service et le pool appropriés et que la restriction d'accès s'applique également au chemin d'accès. Le simple fait de définir un chemin ne rend pas pour autant le contenu accessible via HTTP.

Dans un environnement déjà configuré et sécurisé en local, la commande de terminal suivante lit la sortie JSON. Elle suppose qu'un hôte virtuel HTTP local correspondant est accessible à l'adresse indiquée. Dans le cas contraire, vous devrez adapter l'adresse, le routage de l'hôte et, le cas échéant, le protocole TLS à votre environnement ; cette requête ne modifie aucune configuration.

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

Dans la réponse, vérifie notamment le nom du pool. Un message d'erreur ou une sortie inattendue de l'application peut indiquer un routage incorrect ; un blocage d'accès peut également empêcher la récupération. Vérifie alors la configuration du serveur web concerné et les journaux, au lieu de désactiver la protection trop hâtivement.

Comment bien interpréter et calculer les indicateurs clés

Les valeurs d'état décrivent différentes périodes : certaines indiquent l'état au moment de la consultation, d'autres comptabilisent des événements ou enregistrent une valeur maximale depuis le démarrage. Pour établir un diagnostic, cette distinction est plus importante qu'une simple valeur anormale. Le tableau suivant répertorie les informations essentielles.

Pour une débit de connexiontu soustrais deux valeurs de accepted conn les uns des autres et divise la différence par le temps écoulé. Exemple de calcul hypothétique, sans mesure : si le compteur passe de 12 000 à 12 600 en 60 secondes, cela correspond en moyenne à dix connexions supposées par seconde. Cela ne permet toutefois pas de déduire directement le nombre de pages consultées ni la latence de l'application.

Enregistre l'heure et l'identifiant du pool à chaque point de mesure. Après un redémarrage du FPM, les valeurs d'état sont réinitialisées ; une différence au-delà de cette coupure ne constitue donc pas un débit valide. Détecte une baisse du compteur ou une modification de l'heure de début et recommence le calcul pour la nouvelle période.

À l'adresse suivante : max children reached le gestionnaire de processus joue un rôle déterminant : la configuration d'exemple de PHP 8.4.21 décrit le compteur pour les modes « dynamic » et « ondemand ». En mode « static », tu ne dois pas considérer une valeur nulle comme une preuve de capacité disponible. Pour slow requests le seuil et le slowlog doivent être configurés correctement ; le seuil détermine quelles requêtes longues sont prises en compte.

Comparer les formats de sortie et les détails du processus

La version abrégée permet d'avoir une vue d'ensemble de l'ensemble de la piscine. Le choix du format dépend de la manière dont vous souhaitez traiter les valeurs : à la main ou régulièrement via un système de surveillance. Le paramètre full ajoute des détails sur le processus à la sortie ; il ne s'agit pas d'un format d'échange autonome.

Le manuel PHP documente également les formats XML et HTML. En cas d'accès automatisé, vérifie la version de FPM effectivement installée et ses sorties avant de te fier à certains champs ou détails relatifs aux processus. Tu devrais notamment vérifier la combinaison entre OpenMetrics et full vérifier dans sa propre version, au lieu de partir du principe que les données de processus individuelles sont disponibles.

Le Durée de la requête Dans la version « Full », cette valeur est exprimée en microsecondes. Pour un processus actif, elle indique la durée de la requête en cours de traitement ; pour un processus inactif, elle fait référence à la dernière requête traitée. Une valeur élevée pour un worker libre ne signifie donc pas que celui-ci est encore occupé à traiter la requête.

Les champs last request cpu et last request memory sont affichées comme « zéro » pour les processus en cours d'exécution, car leur évaluation n'a lieu qu'une fois la requête terminée. Ces valeurs nulles ne signifient donc pas qu'il n'y a pas de consommation de CPU ou de mémoire. Des consultations répétées peuvent indiquer si un processus reste actif plus longtemps ; elles ne remplacent toutefois pas un traçage complet de l'application.

Analyser les files d'attente et les requêtes lentes

Si la file d'attente Si cela se produit régulièrement alors que de nombreux processus sont actifs et que seuls quelques-uns sont libres, un pool saturé constitue une hypothèse de travail plausible. Une seule vérification ne suffit pas : comparez plusieurs moments et observez si, parallèlement, les temps de réponse aux requêtes augmentent. La valeur maximale de la file d’attente ne permet pas à elle seule de déterminer si des requêtes sont encore en attente.

Comparez cette période avec les journaux FPM, l'utilisation du processeur et la mémoire disponible. Tenez également compte de la base de données, du cache et des services externes : si PHP attend une dépendance lente, les workers restent occupés, même si une puissance de calcul supplémentaire ne suffit pas à elle seule à résoudre le problème. La page d'état affiche l'occupation, mais n'en indique pas la cause de manière fiable.

Consultez à plusieurs reprises la version complète protégée pendant une phase notable. Une durée de requête prolongée pour un même processus actif peut indiquer qu'un worker est occupé depuis longtemps ; vérifie l'état du processus, car dans le cas d'un processus inactif, la durée se rapporte à sa dernière requête. Le PID, l'URI et le script aident à l'identification, mais ne fournissent pas une trace complète.

Dans le cas d'un contrôleur frontal notamment, un même nom de script peut couvrir de nombreuses fonctions différentes de l'application. Complète donc cette observation par un traçage de l'application et un Slowlog. C'est son seuil qui détermine quelles requêtes longues sont prises en compte ; l'absence d'entrée ne prouve pas que toutes les requêtes étaient rapides. Pour savoir comment analyser ces résultats de manière plus approfondie, consultez l'article consacré à Analyse du journal des ralentissements de PHP-FPM.

Pour effectuer la comparaison, note la plage horaire et le pool concerné. Tu pourras ainsi vérifier, par exemple, si une requête de base de données lente coïncide avec les workers occupés à ce moment-là ou si la file d'attente avait déjà commencé à s'allonger auparavant. Une corrélation permet d'affiner la recherche, mais ne remplace pas pour autant l'examen de la requête en question.

Surveillance et pannes de la page d'état

Pour les pics de charge récurrents, des requêtes régulières et protégées sont plus pertinentes que des contrôles ponctuels. Le format JSON se prête bien au traitement automatisé ; OpenMetrics constitue une alternative si la version de PHP installée et le client de surveillance sont compatibles. Enregistrez, pour chaque point de mesure, l'heure et l'identité du pool afin de ne pas comparer par inadvertance des pools différents.

Traite consultations manquantes comme des événements distincts et non comme des valeurs nulles. Une lacune peut être due au réseau, à la protection d'accès ou au service d'état ; elle n'indique en soi ni un pool vide ni une défaillance de l'application. Conservez donc également les erreurs et les dépassements de délai liés à la requête, afin que la lacune reste visible lors de l'analyse ultérieure.

Identifie également les réinitialisations des compteurs cumulés après un redémarrage du FPM. Une différence négative entre deux valeurs ne correspond pas à un débit de connexion négatif ; recommence le calcul après la remise à zéro et tiens compte de l'intervalle interrompu. L'heure de démarrage et l'affectation au pool aident également à situer une telle rupture dans l'historique.

Si la requête d'état s'exécute via le même pool que l'application, elle peut attendre d'elle-même lorsque les workers sont saturés. Pour cette situation, pm.status_listen un écouteur FastCGI distinct doté d'un pool interne fonctionnant de manière indépendante. Il permet d'effectuer un diagnostic d'état lorsque le pool principal est occupé ; il n'augmente toutefois pas la capacité de traitement de ce dernier.

Le listener supplémentaire nécessite un routage du serveur web protégé et explicitement attribué. Sécurisez également son accès FastCGI et, après avoir validé une modification, vérifiez si la requête renvoie bien l'état du pool souhaité. Ainsi, le diagnostic reste séparé du chemin d'accès normal à l'application, sans rendre les données d'état accessibles au public.

Examiner les résultats et choisir les mesures à prendre

Un ping FPM et la page d'état apportent des réponses à des questions différentes. Le ping indique si FPM répond à la requête correspondante ; il ne fournit pas d'informations équivalentes sur les workers disponibles ou les requêtes en attente. Un ping réussi ne suffit donc pas à lui seul à écarter tout risque de surcharge du pool d'applications.

Si les chiffres du processus ne correspondent pas aux journaux ou à d'autres observations, vérifie d'abord l'affectation au pool, l'heure de l'appel et la possibilité d'un redémarrage. Comparez ensuite ces valeurs avec d'autres données de processus et d'exploitation disponibles. Considérez d'abord cet écart comme un constat en suspens, plutôt que d'en déduire immédiatement une cause ou une modification de configuration nécessaire.

Si les requêtes « Full » répétées et les entrées du « Slowlog » présentent les mêmes schémas de requêtes longues, examinez d'abord les chemins d'application concernés. En revanche, si le ralentissement provient d'une base de données ou d'un service externe, leur analyse peut s'avérer plus efficace qu'une simple modification du nombre de workers. L'essentiel est de s'assurer que la mesure prise s'attaque à la cause observée, et pas seulement à un symptôme isolé.

Une adaptation de pm.max_children Cette option peut être envisagée s'il est prouvé que le pool fonctionne à pleine capacité et que le processeur, la mémoire ainsi que les services en aval sont capables de supporter un parallélisme supplémentaire. Un nombre plus élevé de workers nécessite davantage de ressources et peut accroître la pression sur ces services. Il n'existe donc pas de chiffre universel ; le mode de fonctionnement du gestionnaire de processus doit être pris en compte dans l'évaluation.

Après avoir déployé une modification, comparez à nouveau ce même pool dans des conditions de charge aussi similaires que possible : la file d'attente, les temps de réponse, les erreurs et la consommation de ressources vont de pair. Notez également si une mesure n'apporte aucune amélioration ou si elle alourdit davantage une dépendance. Ce n'est qu'après cela que Comparaison avant-après permet de prendre une décision fondée quant à la suite à donner.