request_slowlog_timeout = 10s : cette seule ligne, ajoutée à un fichier de pool PHP-FPM, suffit à transformer un serveur muet en serveur qui raconte enfin ce qui se passe quand une page WordPress met un temps anormal à répondre. Sans elle, un administrateur ne dispose que du symptôme, la lenteur, sans jamais voir la cause.
Le slowlog est une fonctionnalité native de PHP-FPM, distincte des journaux d’erreurs classiques. Elle capture la pile d’appels PHP exacte d’une requête au moment où elle dépasse un seuil de durée défini, sans attendre qu’elle se termine. C’est l’outil le plus direct pour identifier un script WordPress qui bloque un pool par intermittence, sans avoir à reproduire le problème à la main.
Activer le slowlog sur un pool
La configuration se fait dans le fichier de pool concerné, généralement situé sous /etc/php/7.4/fpm/pool.d/ selon la distribution et la version de PHP installée. Deux directives suffisent pour activer la capture :
slowlog = /var/log/php7.4-fpm-slow-monsite.log
request_slowlog_timeout = 10s
Le chemin de slowlog doit pointer vers un fichier accessible en écriture par l’utilisateur du pool. Le seuil de request_slowlog_timeout se choisit en fonction du temps de réponse normal du site : dix secondes est un point de départ raisonnable pour un site WordPress classique, à ajuster ensuite selon les faux positifs observés. Après modification, un redémarrage du service est nécessaire :
systemctl restart php7.4-fpm
Comprendre ce que le fichier journal contient
Une fois le seuil dépassé par une requête en cours d’exécution, PHP-FPM écrit dans le fichier de slowlog la pile d’appels complète, fonction par fonction, avec le fichier source et le numéro de ligne de chacune. Cette trace ressemble à une trace d’exception, mais elle est produite alors que le script est toujours en train de s’exécuter, ce qui est précisément ce qui la rend utile pour un blocage encore en cours.
La première ligne du bloc indique l’heure, le PID du processus concerné et l’URL de la requête. Viennent ensuite les appels de fonctions, du plus récent au plus ancien, ce qui permet de remonter jusqu’au point d’entrée, souvent un hook WordPress comme the_content ou wp_head, puis jusqu’à la fonction précise, parfois une requête vers une API distante ou une boucle de traitement d’image.
Lire une trace concrète
Voici à quoi ressemble une entrée typique de slowlog une fois capturée sur un pool WordPress :
[20-Feb-2020 07:41:12] [pool monsite] pid 18422
script_filename = /var/www/monsite/wp-load.php
[0xb2d3a4d0] curl_exec() /var/www/monsite/wp-content/plugins/meteo-widget/inc/api.php:44
[0xb2d3a460] file_get_contents() /var/www/monsite/wp-content/plugins/meteo-widget/inc/api.php:40
[0xb2d3a3d0] do_action('wp_footer') /var/www/monsite/wp-includes/template.php:812
Dans cet exemple, un appel curl_exec() effectué depuis une extension tierce, accroché au hook wp_footer, bloque le script en attendant la réponse d’une API météo distante. Sans le slowlog, le seul symptôme visible aurait été des temps de réponse aléatoirement longs sur les pages du site, sans indication de l’origine.
Étapes pour diagnostiquer un pool à partir du slowlog
- Activer
slowlogetrequest_slowlog_timeoutdans le fichier de pool concerné, puis redémarrer PHP-FPM. - Laisser tourner suffisamment longtemps pour capturer plusieurs occurrences du ralentissement, en surveillant le fichier avec
tail -f. - Repérer, dans chaque trace, la fonction la plus profonde et le fichier source associé.
- Vérifier si le même hook ou la même extension revient dans toutes les traces capturées.
- Une fois le script identifié, remonter la chaîne d’appels jusqu’au plugin ou au thème en cause.
Limites et précautions
Un seuil trop bas génère un fichier volumineux et bruyant, avec des traces pour des requêtes simplement un peu lentes plutôt que réellement bloquantes. Un seuil trop haut, à l’inverse, risque de ne rien capturer si le ralentissement observé reste sous la barre fixée. Il vaut mieux commencer large, dix à quinze secondes, puis resserrer progressivement une fois le comportement du site mieux connu.
Sur nos serveurs, nous laissons le slowlog actif en permanence avec un seuil de dix secondes : le fichier reste petit tant que rien d’anormal ne se produit, et il devient précieux le jour où un site se met à ralentir sans raison apparente.
Le slowlog ne dit rien, en revanche, sur le dimensionnement du pool lui-même : le nombre de processus enfants disponibles, la stratégie de gestion choisie entre les modes dynamiques ou statiques, ou la mémoire allouée à chaque processus. Ces réglages relèvent d’un travail distinct, une fois le script fautif identifié et corrigé ou isolé.
En résumé
Le slowlog PHP-FPM transforme un symptôme flou, la lenteur intermittente, en une trace d’appel exploitable, fonction par fonction. Deux lignes de configuration, un redémarrage du service, et une lecture attentive du fichier généré suffisent à remonter jusqu’au plugin ou au hook WordPress responsable, sans avoir à instrumenter le code applicatif ni à deviner à l’aveugle.
