Sites web
Performance du site et APM
Application Performance Monitoring tells you where your site's time actually goes: response time percentiles, the slowest URLs, the slowest database queries, and how hard PHP is working. This guide…
Performance du Site et Surveillance des Performances
La surveillance des performances des applications vous montre où votre site dépense réellement son temps : les percentiles de temps de réponse, les URL les plus lentes, les requêtes de base de données les plus lentes et la charge de travail de PHP. Ce guide couvre l'activation de la surveillance des performances, la lecture de chaque panneau et la prise de mesures en fonction de ce qu'il affiche.
Où se trouve la surveillance des performances dans KPanel
- Connectez-vous à KPanel.
- Cliquez sur Websites dans la barre latérale gauche, puis cliquez sur le site.
- Dans l'onglet du site, ouvrez WordPress, puis APM.
L'adresse directe est /websites/<site-id>/performance.

La surveillance des performances est un droit du plan. Elle est incluse avec Managed WordPress Pro. Sur tout autre plan, la page affiche un panneau de mise à niveau expliquant ce que couvre la surveillance des performances au lieu des tableaux de bord. Si vous voyez ce panneau, la fonctionnalité n'est pas disponible sur votre plan actuel plutôt que désactivée.
Activation de la Surveillance des Performances
La surveillance des performances est désactivée jusqu'à ce que vous l'activiez. Sur un plan éligible, la page affiche une carte Application Performance Monitoring avec un bouton Enable APM.
L'activation ajoute un journal d'accès léger et un suivi des demandes lentes au niveau du processus PHP. Elle n'injecte rien dans vos pages et n'ajoute aucun travail à la demande d'un visiteur, elle est donc sûre de laisser activée en permanence.
Une fois activée, la page affiche un badge APM Active avec la date d'activation, un bouton Refresh et un bouton Disable APM. Les métriques n'apparaissent qu'après l'arrivée du trafic réel, donc un site peu actif affiche Waiting for requests pendant un certain temps.
Temps de Réponse
La première carte contient quatre chiffres de la dernière heure, avec le nombre de demandes et l'heure de capture dans son en-tête.
| Métrique | Ce qu'elle signifie |
|---|---|
| Médiane (P50) | La moitié des demandes étaient plus rapides que cela |
| P95 | 95 % des demandes étaient plus rapides que cela |
| P99 | 99 % des demandes étaient plus rapides que cela |
| Taux d'Erreur 5xx | La part des demandes qui ont échoué avec une erreur serveur |
Chaque tuile est codée par couleur pour 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 terrible signifie que la plupart des demandes vont bien et qu'une minorité sont lentes, ce qui est la signature classique d'une page lente, d'une requête lente ou d'un cache qui rate sur certaines URL. Une mauvaise médiane signifie que tout le site est lent et la cause est généralement structurelle : un plan sous-dimensionné, un thème lourd ou la mise en cache désactivée.
Le taux d'erreur 5xx est le seul chiffre qui devrait être zéro. Tout ce qui reste au-dessus de zéro signifie que les visiteurs voient des défaillances.
Processus PHP
La carte PHP Workers affiche trois chiffres :
- Active Workers : combien de processus PHP traitent actuellement des demandes.
- Slow Requests : les demandes qui ont dépassé le seuil de demande lente et ont été enregistrées.
- Total Handled : les connexions acceptées depuis le démarrage du pool.
Les processus actifs sont un signal de saturation. S'ils restent bloqués près de leur limite pendant le trafic normal, les demandes font la queue derrière PHP et chaque temps de réponse sur la page ci-dessus est partiellement du temps de queue. C'est un problème de capacité, pas un problème de code, et la solution est un plan plus grand ou moins de travail par demande.
Un nombre de demandes lentes en augmentation avec un volume de demandes stable signifie que quelque chose est devenu coûteux.
Points de Terminaison les Plus Lents
Cette carte répertorie vos URL les plus lentes par temps de réponse P95, chacune avec une barre, le P95 en millisecondes et le nombre d'appels reçus. La couleur marque les plus mauvais contrevenants.
Lisez-le comme une liste restreinte, pas comme un classement. Ce que vous voulez est l'intersection entre lent et appelé fréquemment : une page qui prend quatre secondes et est visitée deux fois par jour compte beaucoup moins qu'une qui prend 900 millisecondes et est visitée dix mille fois.
Coupables courants :
- Pages de recherche qui scannent sans index.
- Listings de catégorie et d'archive qui construisent de grandes requêtes par demande.
- Pages de panier, de paiement et de compte, qui ne sont jamais en cache car elles sont par visiteur. Voir Site Caching pour savoir quels chemins contournent le cache par conception.
- URL d'administration, qui sont toujours dynamiques.
- Tout ce qui appelle une API externe dans la demande, où vous mesurez le serveur de quelqu'un d'autre.
Requêtes Lentes
La carte Slow Queries répertorie les requêtes de base de données dont la moyenne dépasse 100 millisecondes, extraites des propres données de performance de la base de données. Chaque ligne affiche le temps moyen, le temps maximum, le nombre d'appels et le texte de requête normalisé.
Le texte de requête est un digest, avec les valeurs littérales supprimées, donc la même requête avec des paramètres différents se groupe en une seule ligne. C'est ce qui rend le nombre d'appels significatif.
Corriger les requêtes lentes est généralement l'une de trois choses : ajouter un index dont la requête a besoin, réduire la fréquence d'exécution de la requête en mettant en cache son résultat ou supprimer le plugin qui la génère. Une requête avec un très grand nombre d'appels et une moyenne modérée est souvent pire en agrégat qu'un seul cas extrême dramatique.
Si les deux listes des points de terminaison et des requêtes reviennent vides, la carte indique qu'aucune demande lente n'a été détectée, ce qui signifie que tout au cours de la dernière heure était dans les seuils normaux.
Bien Utiliser la Surveillance des Performances
Établissez une ligne de base. Regardez les chiffres quand le site est en bon état, pour savoir à quoi ressemble la normale. Un P95 de 700 millisecondes ne signifie rien jusqu'à ce que vous sachiez qu'il était autrefois de 300.
Changez une seule chose à la fois. Activez un cache, actualisez et comparez. Désactivez un plugin suspect, actualisez et comparez. Les changements par lots ne vous donnent aucun signal.
Actualisez délibérément. Le bouton Refresh relit les métriques à la demande. Les chiffres couvrent la dernière heure, donc donnez un peu de temps à un changement avant de le juger.
Regardez en dehors de la surveillance des performances aussi. La surveillance des performances mesure votre application. Si le problème est le réseau ou le bord plutôt que le code, Site Traffic Analytics et Site Uptime Monitoring le montreront à la place.
Dépannage
La page affiche un panneau de mise à niveau. La surveillance des performances est incluse avec Managed WordPress Pro. Sur d'autres plans, elle n'est pas disponible.
La surveillance des performances est activée mais il n'y a pas de métriques. Pas encore de trafic. Les métriques apparaissent une fois que le site reçoit des demandes.
Les temps de réponse sont bons dans la surveillance des performances mais le site semble lent. La surveillance des performances ne mesure que le temps côté serveur. Le temps passé à télécharger des images, à exécuter JavaScript et à charger des polices dans le navigateur est invisible ici. Si le temps serveur est bon et la page semble toujours lente, le problème est dans l'interface ou dans ce que vous demandez au navigateur de récupérer.
P95 s'est aggravé après une mise à jour de plugin. Vérifiez la liste des points de terminaison les plus lents, puis la liste des requêtes lentes. Un plugin qui a ajouté une requête à chaque chargement de page s'affichera dans les deux.
Tout est lent tout le temps. Vérifiez d'abord les processus PHP pour la saturation. Si les processus sont bloqués, augmentez la capacité ou réduisez le travail par demande avant d'optimiser autre chose.
Erreurs au-dessus de zéro. Corrigez-les avant de vous lancer dans les millisecondes. Commencez par vos journaux et utilisez le bouton Troubleshoot with Kora de l'onglet Error pages du site, qui demande à Kora de lire vos journaux d'erreurs et vos défaillances récentes pour vous. Voir Custom Error Pages.
Pages Connexes
- Site Caching est généralement la plus grande victoire pour un site WordPress.
- Site Security pour l'analyse des vulnérabilités et des malwares sur le même site.
- Taking a Backup avant de commencer à supprimer des plugins.