Vous en avez maintenant l’habitude, je vais vous parler une nouvelle fois du CMS WordPress. Enfin pas directement. J’ai récemment aidé un client qui avait de gros problèmes de performances sur son site web suite à une migration qui ne s’était pas très bien passé.
Il avait déjà augmenté son serveur VPS vers une machine plus puissante, mais rien à faire. Avec un peu de trafic, son site web sous WordPress était extrêmement lent. A priori ce n’était donc pas un souci de puissance du serveur, mais il fallait plutôt aller regarder du côté de l’optimisation. Sauf que pour ça, encore, faut, il savoir ce qu’il se passe réellement sur la machine. Que l’enquête commence !
Les symptômes sur le serveur web
Je me connecte au serveur VPS avec SSH et mon premier réflexe avant de toucher à quoi que ce soit, c’est de regarder ce qu’il se passe. Je lance donc le célèbre htop pour voir si le serveur web est bien au maximum de ses capacités. Effectivement, c’est bien le cas et les 16 cpu sont à 100% ou presque avec une énorme charge sur MySQL alors que de coté de PHP-FPM les choses semblent assez calmes. Je laisse un peu tourner et regarde. Cette charge semble constante avec un trafic relativement modeste par rapport à ce que j’ai l’habitude de gérer sur ce genre de machines. Il y entre 200 et 500 personnes simultanément sur le site web.
Normalement, sur ce genre de serveur avec un WordPress, ça ne devrait pas poser autant de problèmes. Du moins pas consommer autant de ressources. Il y a du code quelque part qui s’accapare toutes les ressources, j’en suis sûr.
Mon intuition me dit que le problème est donc lié à la charge sur le serveur MySQL qui est trop élevée, mais pourquoi ? Qu’est-ce qu’il se passe ? Pour cela, je vais utiliser une commande bien utile que vous pouvez ranger dans votre trousse à outils, car elle vous rendra bien des services si vous administrez des serveurs web et que vous gérez la base de données MySQL / MariaDB.
Voir les requêtes en cours d’exécution avec MySQL et MariaDB
Il y a une commande très utile avec MySQL et MariaDB qui permet de voir les requêtes SQL en cours d’exécution de votre application vers votre base de données. Dans mon cas, je la lance pour voir ce qu’il se passe avec ce WordPress qui est très lent et peut-être que ça me donnera des indices utiles pour résoudre ce problème. La commande pour voir les requêtes en train d’êtres exécutés sur votre base de données, vous pouvez lancer la commande SQL suivante :
SHOW FULL PROCESSLIST;Elle me donne alors le résultat suivant qui est très intéressant :
Si vous ne voyez pas bien sur l’image, j’ai donc les lignes suivantes qui s’enchaînent en continu et chaque fois que je lance SHOW FULL PROCESSLIST; elles changent.
| 4148 | myuser | localhost | sante2 | Query | 3 | executing | SELECT redirect, options FROM wp_404_to_301 WHERE url = '/wp-content/uploads/2024/03/image1.webp' AND redirect IS NOT NULL LIMIT 0,1 |
| 4149 | myuser | localhost | sante2 | Query | 3 | executing | SELECT redirect, options FROM wp_404_to_301 WHERE url = '/wp-content/uploads/2024/03/image2.webp' AND redirect IS NOT NULL LIMIT 0,1 |
| 4150 | myuser | localhost | sante2 | Query | 2 | executing | SELECT redirect, options FROM wp_404_to_301 WHERE url = '/wp-content/uploads/2024/03/image3.webp' AND redirect IS NOT NULL LIMIT 0,1 |C’est un résultat très intéressant et je remercie cette commande SQL qui me permet de résoudre et surtout d’identifier directement 2 problèmes en 1 pour permettre que tout rentre dans l’ordre.
Interpréter le résultat de SHOW FULL PROCESSLIST;
D’après ces lignes et suite à une rapide analyse, une extension semble utiliser de manière démesurée les ressources, car elle n’est sûrement pas très bien optimisée. Le problème de performance est donc encore une fois lié à une extension pas forcément prévue pour supporter un peu de charge comme c’est souvent le cas. Après quelques recherches, j’ai rapidement trouvé la coupable.
Si cette extension 404 to 301 – Redirect, Log and Notify 404 Errors fait ça, c’est parce que lors de la migration, il y a des images qui n’ont semble t’il pas participé au voyage. L’extension génère alors énormément de logs directement dans la base de données, car les images sont manquantes dans certains articles. Il y a quand même un peu de trafic sur ce site et vu que ce n’est pas très bien optimisé, ça consomme énormément de ressources inutilement à chaque visiteur.
Une fois directement l’extension désactivée, il y en avait beaucoup sur le WordPress, les choses sont très rapidement rentrée dans l’ordre. Cela m’a aussi permis d’avertir le client qu’il avait un problème sur des milliers de pages. Il y avait vraiment un gros problème d’images absentes qui génèrent des erreurs. Avec WordPress, je vois chaque jour des choses très étonnantes, mais c’est ce que j’aime. Une chose est sûre, c’est grâce à cette commande SQL SHOW FULL PROCESSLIST; que j’ai pu trouver très rapidement le problème.
Donc si vous cherchez une piste de départ pour vos investigations et que vous avez une grosse charge sur votre base de données, je vous la conseille vivement de l’utiliser.