Analyser correctement le « slowlog » de PHP-FPM : identifier avec certitude les goulots d'étranglement en matière de performances

Je vais te montrer comment Journal des opérations lentes de PHP-FPM analyses de manière ciblée, interprètes correctement les traces d'exécution et en déduis des mesures claires pour réduire la latence. Tu pourras ainsi identifier de manière fiable les goulots d'étranglement en termes de performances, hiérarchiser les mesures à prendre et accélérer sensiblement les temps de chargement pour les utilisateurs.

Points centraux

• Backtrace Lire : la trame #0 indique la plaquette de frein actuelle.
• Délai d'attente Choisir : commencer par un niveau élevé, puis diminuer progressivement.
• Corrélation À l'aide du journal d'accès : identifier avec certitude les URL lentes.
• Échantillon compter : donner la priorité aux fonctions récurrentes.
• Corrections de code déduire : aborder de manière ciblée les bases de données, les API, les boucles et les plugins.

Qu'est-ce que le « Slowlog » de PHP-FPM ?

Le Slowlog enregistre, pour les requêtes longues, un Backtrace dans un fichier journal et enregistre ainsi le point d'exécution actuel sans interrompre la requête. Je peux ainsi identifier immédiatement quel script, quelle URL et quelle fonction bloquent le passage. Les entrées contiennent l'horodatage, le pool, le nom du fichier de script, l'URI de la requête et la chaîne d'appels de fonctions. De ce fait, le slowlog se distingue clairement des journaux d’erreurs classiques, car il documente les performances et non les erreurs. Pour les sites fortement sollicités, tels que les backends WordPress, il fournit des indications rapidement exploitables sur les requêtes coûteuses, les rendus trop lourds ou les opérations d’E/S bloquantes. Quiconque comprend ces instantanés peut très rapidement cause principale cerner le problème et planifier des mesures.

Voici comment fonctionne le Slowlog au quotidien

Une fois activé, PHP-FPM envoie un message lorsque le seuil défini est dépassé. Instantané de la pile dans le journal, tandis que la requête se poursuit. Chaque entrée commence généralement par „ #0 “, c'est-à-dire à l'endroit où du temps est actuellement perdu. Entre les blocs, je remarque souvent des lignes vides, ce qui facilite la séparation des événements. Cette méthode fournit des échantillons plutôt que des profils complets, mais elle offre en contrepartie des indications précises sur les véritables freins, tels que les chemins de modèles complexes, les hooks orphelins ou les appels réseau lents. Lors des phases de forte affluence, je relie ces indications aux pics de charge, ce qui me permet de classer clairement les sections de code. Dès que j’observe des schémas récurrents, j’adapte par exemple pm.max_children et utilise pour cela les informations provenant de Régler correctement la valeur de pm.max_children.

Activer et configurer Slowlog

J'active la fonction dans le pool concerné et je définis le chemin d'accès, le délai d'expiration et la profondeur de la trace, afin que la Évaluation reste gérable. Ensuite, je redémarre PHP-FPM et je vérifie si le fichier journal est accessible en écriture avec les droits de l’utilisateur du pool. Je définis souvent une valeur initiale de 5 secondes afin de détecter dans un premier temps les anomalies flagrantes sans saturer le système de données de journalisation. Ensuite, je réduis progressivement cette valeur dès que les problèmes les plus importants ont été résolus. Pour que les journaux restent gérables, je limite la profondeur de trace à 20 à 30 trames, ce qui suffit généralement dans la pratique. C’est ainsi que je maintiens la Taille du fichier sous contrôle et ne néglige aucun détail important.

Réglage	Objectif	valeur initiale	Remarques
slowlog	Chemin d'accès au fichier journal	/var/log/php-fpm/www-slow.log	Vérifier les chemins d'accès en fonction de la distribution ; droits d'écriture pour www-data assurer
request_slowlog_timeout	Seuil pour „ lent “	5 s	Commencer haut, puis plus tard abaisser (par exemple, 2 à 3 s)
request_slowlog_trace_depth	Profondeur maximale du backtrace	20–30	Veillez à ce que les traces restent lisibles, sans Informations essentielles perdre

Trouver un fichier journal et le parcourir rapidement

Je vérifie d'abord les chemins d'accès configurés et j'ouvre le fichier journal avec less ou vérifie les dernières lignes à l'aide de tail -40. Je vois ainsi immédiatement si des entrées arrivent et quels scripts reviennent régulièrement. Pour avoir une vue d'ensemble rapide, je porte mon attention sur les noms de fichiers, les pools concernés et les URI qui sortent du lot. Si je ne trouve aucune entrée, j’active les options dans le pool, je recharge le service et je vérifie les propriétaires ainsi que les droits. Dans les environnements gérés, je consulte également le panneau de configuration ou les scripts de démarrage afin de m’assurer que le slowlog suit.

Reconnaître des blocs et compter les motifs

Chaque entrée apparaît sous forme de bloc, souvent séparé par un Ligne vide, ce qui facilite le comptage. Je me base sur les lignes „ #0 “, car elles indiquent le point d'exécution actuel où le temps s'écoule. À l'aide de simples pipelines shell, je filtre les fonctions les plus gourmandes en temps et j'identifie les endroits qui ralentissent le plus souvent le système. Je donne ainsi la priorité aux fonctions qui, cumulées, prennent le plus de temps. Je vérifie ensuite si ces points sensibles n’apparaissent qu’en cas de pics de charge ou s’ils posent des problèmes de manière constante. Ce classement détermine la Ordre mes mesures.

Lire les entrées : de la trame #0 jusqu'au début

Lorsque je lis les entrées, je commence par celle qui se trouve en haut, à savoir #0 et je descends pas à pas pour comprendre le chemin parcouru depuis le point d'entrée jusqu'à l'endroit où je me trouve. De longues chaînes de modèles indiquent un rendu fastidieux, un grand nombre de hooks suggère un surcroît de plugins et une forte proportion de requêtes SQL laisse supposer un manque d'index. Je note les numéros de ligne, les noms de fonctions et les chemins d’accès aux fichiers afin de retrouver rapidement le code. Si la pile semble comporter des boucles d’attente ou des opérations répétitives, je vérifie la mémoire tampon et la mise en cache. Ainsi, je ne perds pas de temps à Localisation du problème dans le code.

Corréler les fichiers Slowlog avec les fichiers journaux d'accès

Je relie le Slowlog aux fichiers journaux du serveur web afin de pouvoir identifier les requêtes lentes d'un URL Je peux les associer. Grâce aux horodatages et, éventuellement, aux PID, je retrouve les entrées correspondantes dans les fichiers journaux d'Nginx ou d'Apache. Cela me permet d'identifier les paramètres, les user-agents et les temps de réponse en dehors de PHP. Si des visiteurs récurrents ou des chaînes de requête identiques apparaissent, je lance un test en reproduisant précisément ces scénarios. Je repère ainsi rapidement les cas reproductibles et je conserve la Durée de l'analyse en bref.

Réduire la valeur seuil de manière itérative

Je commence par un seuil généreux, en corrigeant d'abord les plus gros Fugueurs puis je le réduis progressivement. Ce processus réduit le volume des logs et me permet de concentrer mon énergie sur les corrections qui en valent la peine. Après chaque cycle d’optimisation, je choisis un seuil plus bas et je collecte à nouveau des ensembles de données. Je passe ainsi d’un filtrage grossier à un réglage fin, sans me perdre dans le bruit. Il en résulte des ajustements ciblés et une clair Aperçu des goulots d'étranglement restants.

Du slowlog à la solution : corrections typiques

Si le cadre supérieur affiche des fonctions de base de données, je vérifie les requêtes SQL à l'aide de EXPLAIN, je crée les index manquants et je limite les ensembles de résultats. Pour les services distants, je réduis les délais d'attente, je traite les réponses de manière asynchrone ou je mets les résultats en cache. Si je repère des boucles coûteuses, je simplifie la logique, je réduis le nombre de passages et j'utilise des structures plus efficaces. Dans WordPress, je repère les hooks récurrents, je remplace les extensions lourdes et j’opte pour un thème plus léger. Si le nombre de processus PHP bloque l’exécution, je surveille les temps d’attente et je consulte, en complément de Traces de retour ainsi que les files d'attente, par exemple via Mise en file d'attente des requêtes PHP.

Fonctionnement continu : gestion efficace des journaux

Je ne règle pas la journalisation au maximum en permanence, afin que la Charge d'E/S reste gérable. Je procède plutôt par phases : évaluation active, optimisation, puis retour à un niveau modéré. Grâce à Logrotate, je garde les fichiers légers et j’archive les anciennes données sous forme compressée. Une fois l’analyse terminée, je relève le seuil ou je désactive temporairement le slowlogging. De plus, je consigne les conclusions et les corrections afin que les audits ultérieurs puissent disposer d’une vision claire trace trouver.

Diagnostic d'hébergement : distinguer le serveur de l'application

La présence de nombreuses trames Slowlog identiques associée à une charge élevée du processeur suggère que Code d'application, tandis que l'absence d'entrées du côté du serveur indique plutôt un problème au niveau des E/S, du réseau ou du serveur de base de données. Dans de tels cas, je compare le TTFB, les temps PHP et la latence en amont afin de localiser le goulot d'étranglement. Si je constate des files d’attente et des temps d’attente élevés avant l’exécution, je vérifie les limites et le nombre de processus. Pour ce faire, j’enrichis mon diagnostic avec des informations sur le traitement des requêtes et je tiens compte des éventuelles limites qui ralentissent ce traitement. Pour une analyse approfondie, je consulte, en plus des journaux, les indications relatives à Régler correctement la valeur de pm.max_children ou des articles liés aux délais d'attente, afin que je puisse Capacité en fonction de ce qui me semble le plus judicieux.

Exemple concret : un backend WordPress lent

Je mets request_slowlog_timeout Je commence par régler ce paramètre sur 5 secondes, je redémarre PHP-FPM et je collecte des données pendant 30 à 60 minutes en conditions réelles de charge. Ensuite, je recense les fonctions „ #0 “ les plus fréquentes et je recherche les hooks récurrents ou les appels WP_Query coûteux. Si des services externes interviennent, je mesure les temps de réponse et je mets les résultats en cache de manière ciblée. Si les consultations de pages sont ralenties par des accès liés à la session, je vérifie le comportement de verrouillage et, si possible, je déplace les tâches liées à la session hors du chemin critique. Notamment lors des connexions et des actions d’administration, je teste les paramètres et désactive les messages d’avertissement. Verrouillage de session PHP pour que mon Backend réagit plus rapidement.

Conception du pool et droits : une base solide pour des slowlogs exploitables

Je sépare les applications dans des dossiers distincts piscines avec des noms clairs (par exemple www, admin, api), définissez des écouter-Prises et personnalisées slowlog-chemins d'accès. Cela me permet de mettre plus facilement en correspondance les entrées et d'éviter les confusions. Il est important que les chemins d'accès soient cohérents Droits sur les fichiers: L'utilisateur du pool (souvent www-data) doit disposer de droits d'écriture sur le chemin d'accès aux fichiers journaux et dans le répertoire. Dans les configurations de conteneurs ou chroot, je vérifie si les chemins d'accès existent dans l'espace de noms et s'ils sont persistants ; sinon, les fichiers journaux disparaissent au redémarrage.

Lire en détail un bloc Slowlog et l'analyser automatiquement

En général, les entrées commencent par l'horodatage, le pool, le nom du script et l'URI de la requête, suivis des trames. Je compte les lignes „ #0 “ et je les regroupe par nom de fonction afin de mettre en évidence les points chauds. À l'aide de simples pipes, j'extrais les freins :

grep -E "^#0|request.uri|script_filename" /var/log/php-fpm/www-slow.log | sed 's/  */ /g'

Ou alors, je vais énumérer les « top frames » les plus courantes :

grep "^#0" /var/log/php-fpm/www-slow.log | awk -F": " '{print $2}' | awk '{print $1}' | sort | uniq -c | sort -nr | head

Si je souhaite inclure l'URL et le fichier, je prépare des blocs à l'aide de awk et note-moi les meilleures combinaisons entre fonction, URI et script. C'est ainsi que je hiérarchise les corrections qui apportent le plus d'avantages.

Carte des délais d'expiration : comment Slowlog, PHP et le serveur web fonctionnent ensemble

Pour établir un diagnostic précis, je prescris tous Délais d'attente : request_slowlog_timeout déclenche le snapshot, max_execution_time limite la durée d'exécution de PHP dans le script, request_terminate_timeout peut forcer l'arrêt du processus FPM. Intervenir au niveau du serveur web fastcgi– ou. proxy-Délais d'expiration (par exemple,. fastcgi_read_timeout) et les délais d'attente côté client. Si je configure le slowlog au-dessus en cas de délai d'attente du serveur, je perds des données ; s'il parmi lesquels, j'obtiens des instantanés utiles avant que les requêtes ne s'interrompent. C'est pourquoi je conserve délibérément cet ordre : délai d'expiration du serveur web > arrêt de PHP > slowlog > latence de la cible.

Intégrer la gestion des statuts FPM, des files d'attente et des processus

Le Slowlog montre que, où Le temps est perdu – le statut FPM révèle que, pourquoi Les requêtes sont en attente. J'active le point de terminaison d'état, j'observe idle, active et listen queue et je les compare aux horodatages du Slowlog. Si la file d'attente s'allonge alors que de nombreux workers sont bloqués dans les mêmes fonctions, c'est le code qui constitue le goulot d'étranglement ; si la file d'attente s'allonge sans augmentation du Slowlog, c'est soit un manque de capacité, soit un frein en amont. Sur cette base, j'ajuste pm-Paramètres (dynamic/ondemand), pm.max_children et, le cas échéant,. pm.max_requests, afin de détecter les fuites de mémoire ou la fragmentation.

Particularités des conteneurs et des environnements gérés

Dans Docker/Kubernetes, FPM envoie souvent ses journaux vers stdout/stderr ou dans des chemins collectés par des agrégateurs de journaux. Je choisis délibérément un a Supprimer, pour éviter d'avoir des entrées en double ou manquantes. Avec error_log = /proc/self/fd/2 et un slowlog-Les instantanés restent disponibles tant que le chemin d'accès pointe vers un volume persistant. Dans les configurations gérées, je vérifie si l'hébergeur active ou limite les journaux de lenteur, et j'ajuste les intervalles afin de ne pas entrer en conflit avec les rotations.

Confidentialité et sécurité : des journaux d'activité sans risque

Les traces d'exécution peuvent contenir des informations sensibles Paramètres, ne contiennent ni chemins d'accès ni identifiants de session. Je minimise les risques en supprimant les chaînes de requête des journaux d'accès, en désactivant les messages de débogage dans le code et en limitant le cercle des personnes autorisées à consulter ces données. Pour les échanges avec des tiers, j'anonymise les chemins d'accès et supprime les jetons. Dans les environnements de production, je définis des durées de conservation courtes et j'applique la rotation et la compression des journaux à l'échelle du système.

WordPress : repérer rapidement les schémas récurrents

• WP_Query/WP_Meta_Query: Absence d'index sur postmeta ou si le filtrage s'effectue sur des champs non indexés, le temps d'exécution explose. Je réduis les méta-requêtes, j'utilise des taxonomies ou je crée des index ciblés.
• Transitoires et cache d'objets: De nombreux calculs similaires semblent indiquer l'absence d'un cache persistant. J'active le cache d'objets, j'optimise les clés de cache et les durées de vie (TTL).
• Hooks/Filtres: Les longues chaînes empilées indiquent la présence de plugins superflus. Je passe en revue les hooks les plus gourmands en ressources et je supprime ou remplace les extensions.
• Requêtes HTTP: Les appels API internes (wp_remote_get) doivent utiliser les délais d'expiration, la persistance de connexion et la mise en cache ; dans la mesure du possible, les réponses ne doivent pas bloquer le thread de requête.
• Rendu des modèles: Profondeur get_template_part- Les cascades impliquant des accès aux fichiers bénéficient de la mise en cache et d'une fragmentation réduite.

Éviter les interprétations erronées : ce que le Slowlog ne montre pas

Le « snapshot » est un Instantané. Il ne rend pas compte de toute la durée de vie de la requête, mais de son état au moment où elle a été déclenchée. Pièges courants :

• Biais d'échantillonnage: Des chemins rares, mais extrêmement coûteux, peuvent être perdus si le délai d'expiration est trop court ou si la phase a été brève.
• Appels système bloquants: fopen, stat ou les requêtes DNS apparaissent comme des fonctions PHP, mais le temps d'attente réel se produit au niveau du noyau ou du réseau.
• Chargement automatique: De nombreux petits fichiers inclus sans Opcache entraînent des pertes de performance qui semblent anodines au niveau de la pile. Il suffit de consulter le taux d'accès à l'Opcache pour mieux cerner la situation.

Gérer la CLI, Cron et les webhooks

Tous les problèmes de performances ne passent pas par FPM. Les éléments lourds Cronjobs (par exemple, wp-cron), les workers de file d'attente ou les webhooks bloquent le processeur, les E/S ou la base de données, ce qui détériore indirectement les temps de réponse. J'isole ces charges dans des processus distincts, je les planifie en dehors des pics d'activité et je vérifie qu'elles s'exécutent via HTTP déclenché par FPM plutôt que via la CLI – sinon, cela fausse la vue du slowlog.

Mettre en œuvre la rotation des fichiers journaux de manière pratique

Pour éviter que les slowlogs ne prennent trop de place, je les renouvelle fréquemment et je compresse les anciens fichiers. Un renouvellement typique conserve quelques générations, signale à FPM de rouvrir le fichier et évite les lacunes. Important : après la rotation, il faut réinitialiser FPM (HUP) afin que les nouvelles entrées ne soient pas perdues. J'adapte les paramètres concrets en fonction du trafic, du délai d'expiration et de la profondeur de trace.

Liste de contrôle pour obtenir des résultats rapides

• Activer Slowlog par pool, vérifier les chemins d'accès et les droits.
• Démarrer à 5 s, collecter les entrées, compter les images les plus fréquentes.
• Corrélation avec les journaux d'accès : horodatage, URI, agent utilisateur.
• Vérifier les délais d'attente des serveurs en amont et des serveurs Web.
• Surveiller l'état du FPM et la file d'attente, pm-Ajuster les limites.
• Commencez par résoudre les points sensibles : index SQL, mise en cache, hooks coûteux, E/S.
• Réduire progressivement le délai d'attente, puis effectuer une nouvelle mesure.
• Effectuer la rotation des fichiers journaux, consigner les conclusions, assurer le suivi des modifications.

En bref : comment améliorer vos performances

J'active le Slowlog, je lis les Cadres haut de gamme, je recoupe ces données avec les journaux d'accès et je corrige d'abord les anomalies les plus importantes. Ensuite, j'abaisse le seuil, j'analyse les schémas récurrents et j'applique des corrections ciblées au niveau du code, de la configuration et de la mise en cache. Grâce à la rotation des journaux et à des délais d’expiration modérés, je maintiens la charge d’exploitation à un faible niveau. Pour WordPress, je me concentre sur les requêtes coûteuses, les plugins, les hooks et les éventuels blocages de session. C’est ainsi que j’identifie de manière fiable les véritables Bottlenecks et fournit des réponses nettement plus rapides.