La Surveillance de la performance des applications, pour les sites WordPress et WooCommerce, vous indique où le temps de votre site est réellement consacré : les percentiles de temps de réponse, les URL les plus lentes, les requêtes de base de données les plus lentes et l'intensité de travail de PHP. Ce guide explique comment activer l'APM, lire chaque panneau, et agir en fonction de ce qu'il montre.
Où trouver l'APM dans KPanel
- Connectez-vous à KPanel.
- Cliquez sur Sites web dans la barre latérale gauche, puis cliquez sur le site.
- Dans le menu de gauche du site, ouvrez Performances, puis APM.
L'adresse directe est /websites/<site-id>/performance.
L'APM est un avantage lié au plan. Il est inclus avec Managed WordPress Pro. Sur tout autre plan, la page affiche un panneau de mise à niveau expliquant ce que couvre l'APM plutôt que les tableaux de bord. Si vous voyez ce panneau, la fonctionnalité n'est pas disponible sur votre plan actuel plutôt que désactivée.
Activer l'APM
L'APM est désactivé tant que vous ne l'activez pas. Sur un plan éligible, la page affiche une carte Surveillance de la performance des applications avec un bouton Activer l'APM.
L'activer ajoute un journal d'accès léger et un suivi des requêtes lentes au niveau des workers PHP. Cela n'injecte rien dans vos pages et n'ajoute aucune charge à la requête d'un visiteur, c'est donc sans risque de le laisser actif en permanence.
Une fois activé, la page affiche une pastille APM actif avec la date d'activation, un bouton Actualiser et un bouton Désactiver l'APM. Les métriques n'apparaissent qu'une fois qu'un trafic réel arrive, un site peu fréquenté affichera donc En attente de requêtes pendant un moment.
Temps de réponse
La première carte contient quatre chiffres de la dernière heure, avec le nombre de requêtes et l'heure de capture dans son en-tête.
| Métrique | Ce qu'il signifie |
|---|---|
| Médiane (P50) | La moitié des requêtes ont été plus rapides que cela |
| P95 | 95 pour cent des requêtes ont été plus rapides que cela |
| P99 | 99 pour cent des requêtes ont été plus rapides que cela |
| Taux d'erreur 5xx | La part des requêtes ayant échoué avec une erreur serveur |
Chaque tuile est codée par couleur afin que vous puissiez lire l'état sans connaître les seuils.
Lisez les percentiles ensemble, pas séparément. Une bonne médiane avec un P95 catastrophique signifie que la plupart des requêtes se passent bien et qu'une minorité est pénible, ce qui est la signature classique d'une page lente, d'une requête lente, ou d'un cache qui échoue sur certaines URL. Une mauvaise médiane signifie que l'ensemble du site est lent et la cause est généralement structurelle : un plan sous-dimensionné, un thème lourd, ou une mise en cache désactivée.
Le taux d'erreur 5xx est le seul chiffre qui devrait être nul. Tout ce qui reste durablement au-dessus de zéro signifie que des visiteurs rencontrent des échecs.
Workers PHP
La carte Workers PHP affiche trois nombres :
- Workers actifs : combien de processus PHP traitent actuellement des requêtes.
- Requêtes lentes : les requêtes ayant dépassé le seuil de requête lente et ayant été enregistrées.
- Total traité : les connexions acceptées depuis le démarrage du pool.
Les workers actifs constituent un signal de saturation. S'il reste bloqué près de son plafond pendant un trafic normal, les requêtes font la queue derrière PHP, et chaque temps de réponse sur la page ci-dessus correspond en partie à du temps d'attente. Il s'agit d'un problème de capacité, pas d'un problème de code, et la solution est un plan plus grand ou moins de travail par requête.
Un nombre de requêtes lentes en augmentation avec un volume de requêtes stable signifie que quelque chose est devenu coûteux.
Points de terminaison les plus lents
Cette carte liste vos URL les plus lentes selon le temps de réponse P95, chacune avec une barre, le P95 en millisecondes, et le nombre d'appels reçus. La couleur signale les pires contrevenants.
Lisez-la comme une liste restreinte, pas comme un classement. Ce que vous recherchez, c'est l'intersection entre lenteur et fréquence d'appel : une page qui prend quatre secondes et qui est consultée deux fois par jour compte beaucoup moins qu'une page qui prend 900 millisecondes et qui est consultée dix mille fois.
Coupables fréquents :
- Les pages de recherche qui parcourent sans index.
- Les listes de catégories et d'archives qui construisent de grandes requêtes à chaque appel.
- Les pages de panier, de commande et de compte, qui ne sont jamais mises en cache car elles sont propres à chaque visiteur. Voir Mise en cache du site pour savoir quels chemins contournent le cache par conception.
- Les URL d'administration, qui sont toujours dynamiques.
- Tout ce qui appelle une API externe pendant la requête, auquel cas vous mesurez le serveur de quelqu'un d'autre.
Requêtes lentes
La carte Requêtes lentes liste les requêtes de base de données dont la moyenne dépasse 100 millisecondes, tirées des données de performance propres à la base de données. Chaque ligne affiche le temps moyen, le temps maximal, le nombre d'appels et le texte normalisé de la requête.
Le texte de la requête est un condensé, les valeurs littérales étant supprimées, de sorte que la même requête avec des paramètres différents est regroupée dans une seule ligne. C'est ce qui rend le nombre d'appels significatif.
Corriger des requêtes lentes revient généralement à l'une de ces trois actions : ajouter un index dont la requête a besoin, réduire sa fréquence d'exécution en mettant son résultat en cache, ou supprimer l'extension qui la génère. Une requête avec un nombre d'appels très élevé et une moyenne modérée est souvent pire au total qu'une seule valeur aberrante spectaculaire.
Si les listes de points de terminaison et de requêtes reviennent toutes deux vides, la carte indique qu'aucune requête lente n'a été détectée, ce qui signifie que tout, au cours de la dernière heure, est resté dans les seuils normaux.
Bien utiliser l'APM
Établissez une base de référence. Regardez les chiffres quand le site est en bonne santé, afin de savoir à quoi ressemble la normale. Un P95 de 700 millisecondes ne signifie rien tant que vous ne savez pas qu'il était auparavant de 300.
Changez une seule chose à la fois. Activez un cache, actualisez, et comparez. Désactivez une extension suspecte, actualisez, et comparez. Des changements groupés ne vous donnent aucun signal exploitable.
Actualisez de façon réfléchie. Le bouton Actualiser relit les métriques à la demande. Les chiffres couvrent la dernière heure, laissez donc un peu de temps avant de juger un changement.
Regardez aussi en dehors de l'APM. L'APM mesure votre application. Si le problème vient du réseau ou de la périphérie plutôt que du code, Analyse du trafic du site et Surveillance de la disponibilité du site le montreront à la place.
Dépannage
La page affiche un panneau de mise à niveau. L'APM est inclus avec Managed WordPress Pro. Sur les autres plans, il n'est pas disponible.
L'APM est activé mais il n'y a aucune métrique. Pas encore de trafic. Les métriques apparaissent dès que le site reçoit des requêtes.
Les temps de réponse sont bons dans l'APM mais le site semble lent. L'APM mesure uniquement le temps côté serveur. Le temps passé à télécharger des images, exécuter du JavaScript et charger des polices dans le navigateur est invisible ici. Si le temps serveur est bon et que la page semble quand même lente, le problème se situe dans le front-end ou dans ce que vous demandez au navigateur de récupérer.
Le P95 s'est dégradé après une mise à jour d'extension. Vérifiez la liste des points de terminaison les plus lents, puis la liste des requêtes lentes. Une extension ayant ajouté une requête à chaque chargement de page apparaîtra dans les deux.
Tout est lent en permanence. Vérifiez d'abord la saturation des workers PHP. Si les workers sont bloqués, ajoutez de la capacité ou réduisez le travail par requête avant d'optimiser quoi que ce soit d'autre.
Erreurs au-dessus de zéro. Corrigez-les avant de traquer les millisecondes. Commencez par vos journaux, et utilisez le bouton Dépanner avec Kora sur l'onglet Pages d'erreur du site, qui demande à Kora de lire vos journaux d'erreurs et vos échecs récents à votre place. Voir Pages d'erreur personnalisées.
Pages connexes
- Mise en cache du site est généralement le gain le plus important pour un site WordPress.
- Sécurité du site pour l'analyse des vulnérabilités et des logiciels malveillants sur le même site.
- Effectuer une sauvegarde avant de commencer à supprimer des extensions.