Taux de réussite du cache d'objets WordPress : pertinence et objectifs raisonnables

Ce que stocke le cache d'objets WordPress

Le Cache d'objets WordPress met à disposition des données associées à une clé et au sein d'un groupe. Si WordPress interroge à nouveau cette même valeur, il peut la récupérer dans le cache au lieu de réexécuter le traitement sous-jacent. Cela concerne par exemple les données qui, autrement, devraient être lues dans la base de données ou recalculées.

L'implémentation Core intégrée est, par défaut, lié à la requête: Il conserve ses entrées pendant la durée d'une seule requête. Une consultation ultérieure de la page n'a donc pas automatiquement accès aux valeurs précédemment enregistrées. Néanmoins, le cache permet d'éviter des accès répétés au cours d'une même requête.

Un « drop-in » peut remplacer l'implémentation de base par un cache d'objets persistant remplacer. Ainsi, les entrées appropriées peuvent être conservées au-delà des requêtes individuelles. Redis est une option de backend possible, mais n'est pas une condition préalable à l'utilisation de WordPress ; d'autres approches de backend sont également possibles. Même avec un module de remplacement persistant, certains groupes peuvent continuer à ne s'appliquer qu'à la requête en cours.

Les données transitoires constituent une autre possibilité de stocker des données nécessaires pendant une durée limitée. Grâce à un cache d'objets persistant, elles peuvent y être stockées sans passer, en règle générale, par la base de données. Leur durée de validité ne garantit pas une disponibilité minimale : une valeur peut disparaître plus tôt. Le code de l'application doit donc s'attendre à ce qu'un transient puisse manquer et être capable de régénérer la valeur si nécessaire.

Cette distinction est déterminante pour l'évaluation ultérieure d'un taux de réussite : un accès au cache local lors d'une requête et un accès à un backend externe ne correspondent pas nécessairement au même indicateur. Vérifie donc d'abord quelle implémentation est réellement utilisée et quelles données elle traite de manière persistante.

Distinguer le cache d'objets et le cache de pages

Lorsqu'une page est consultée, un Cache de la page fournir une réponse de page déjà générée. Si la requête y trouve une réponse, elle n'a pas besoin de passer par le même chemin d'application WordPress qu'une requête non mise en cache. Le cache d'objets, en revanche, fonctionne au sein de l'application avec des données mises en cache individuelles, et non avec la réponse de page complète.

Imaginez une page d'article accessible au public : si sa réponse se trouve dans le cache de page, elle peut être servie directement. En revanche, si WordPress doit générer la page, le cache d'objets peut faciliter les accès répétés aux données. La charge de travail ainsi allégée dépend de la requête, des entrées enregistrées et de l'implémentation utilisée.

Cela a des conséquences sur l'interprétation : un bon taux de cache d'objets ne décrit que les accès au cache enregistrés. Il n'indique pas directement combien de visiteurs reçoivent déjà une réponse prête à l'emploi provenant du cache de page, ni à quelle vitesse l'ensemble du site web réagit. En cas de mise en cache de pages intensive, l'intérêt du cache d'objets peut notamment se manifester au niveau des requêtes WordPress restantes.

Le cache du navigateur et le cache d'opcode remplissent également d'autres fonctions. Le cache du navigateur met les ressources à la disposition du visiteur ; un cache d'opcode PHP stocke le code PHP compilé. Ni l'un ni l'autre ne remplacent le stockage de données d'application individuelles dans le cache d'objets, ni la fourniture d'une réponse complète à partir d'un cache de pages.

La constante WP_CACHE À lui seul, cela n'active pas le cache d'objets Redis. Pour disposer d'un cache d'objets persistant, tu as besoin d'une implémentation adaptée et de sa configuration prise en charge. Tu trouveras un exemple supplémentaire illustrant l'interaction entre plusieurs niveaux dans l'article consacré à la Moteur de mise en cache AccelerateWP.

Ce que révèlent les succès et les échecs

A Hit se produit lorsqu'une entrée recherchée est trouvée au niveau de cache considéré. Un Miss ce qui signifie qu'il n'y est pas détecté. Le taux de réussite correspond au rapport entre le nombre de coups réussis et le nombre total de coups réussis et manqués : coups réussis / (coups réussis + coups manqués) × 100. S'il n'y a ni coups réussis ni coups manqués, le taux n'est pas défini pour cette période.

Une erreur n'est pas automatiquement un défaut technique. Lors du premier accès, une entrée peut encore manquer ; même après son expiration, elle doit, le cas échéant, être récupérée ou recréée. Ce qui est déterminant, ce sont les conséquences de ces tentatives infructueuses sur le déroulement concret du processus et la question de savoir s'il est judicieux de réitérer ces accès.

La méthode « Core » de WordPress comptabilise, dans sa propre implémentation, les accès au cache réussis et les échecs. Un plugin « drop-in » peut toutefois remplacer cette implémentation. C'est pourquoi il n'est pas possible de déduire avec certitude, à partir du comptage du noyau, ce que recense un affichage de plugin : vérifie, pour la version utilisée, quels accès et quelle période son indicateur couvre.

Redis signale avec keyspace_hits et keyspace_misses les recherches de clés réussies ou infructueuses dans l'espace de clés Redis. Même une recherche ayant échoué EXISTS-Une faute peut être comptabilisée. Celle-ci Taux de réussite de Redis ne correspond donc pas automatiquement à une part de marché de WordPress ou d'un plugin.

Si une instance Redis est utilisée par plusieurs sites web ou applications, ses compteurs peuvent refléter conjointement le trafic de ces derniers. Sans données de télémétrie distinctes et adaptées, il n’est alors pas possible d’attribuer de manière fiable un quota global à un site WordPress en particulier. Pour toute comparaison, tu dois donc préciser à quel niveau et à quelle instance se rapportent ces chiffres.

Vérifier soigneusement la zone de mesure et les conditions d'accès

Avant de procéder à la mesure, vérifie quelle implémentation du cache d'objets WordPress utilise. Si WP-CLI est disponible et que tu as accès au répertoire WordPress, tu peux y lancer un inventaire en lecture seule à l'aide de la commande suivante :

wp cache type

Ce résultat aide à évaluer la mise en œuvre, mais ne prouve pas que chaque accès pertinent soit enregistré de manière persistante. WordPress permet à un module « drop-in » de remplacer le cache du cœur ; toutefois, certains groupes peuvent ne pas être enregistrés de manière persistante. Notez donc également le module « drop-in » ou le plugin utilisé, ainsi que sa version.

Consultez la documentation de la version concernée pour savoir quels accès sont pris en compte dans les « hits » et les « misses » affichés, et sur quelle période ils sont comptabilisés. Un taux de plugin ne peut être comparé de manière pertinente à un autre indicateur que si le champ de mesure et le mode de comptage sont connus. Il est particulièrement important de savoir si l'affichage correspond à une seule requête ou à une fenêtre plus longue.

Pour Redis, si la connexion et les autorisations sont disponibles, tu peux consulter en lecture seule les statistiques et les informations de mémoire dans une session CLI Redis. Les commandes suivantes ne contiennent délibérément aucune information d'identification :

INFO stats
INFO memory

Documente le Plage de mesure: Quelles instances ou quels nœuds ont été interrogés, et quels autres sites web ou applications les utilisent ? Les compteurs Redis globaux ne peuvent pas être facilement attribués à un site web spécifique lorsqu’ils sont partagés. Vérifiez les résultats avant de les diffuser afin de vous assurer qu’ils ne contiennent pas d’informations opérationnelles sensibles ; ni un vidage ni un test de charge n’est nécessaire pour cet inventaire.

Si vous n'avez pas accès à l'interface CLI de Redis, renseignez-vous auprès de votre hébergeur sur les métriques disponibles et leur champ d'application. De même, un tableau de bord ne constitue une base d'analyse utile que si l'on sait clairement s'il affiche les données d'une même instance, celles de nœuds individuels ou des valeurs déjà agrégées.

Calculer le taux de réussite de Redis sur un intervalle donné

Les statistiques Redis correspondent à des compteurs, et non à une analyse définitive portant sur une période de mesure donnée. Pour effectuer une analyse par intervalle, consultez les valeurs correspondant à keyspace_hits et keyspace_misses au début et à la fin de la même plage horaire définie par la même instance. Note ces deux moments ainsi que l'instance correspondante afin que les relevés correspondent.

Soustrayez ensuite, pour chaque compteur, la valeur initiale de la valeur finale. La Taux de réussite par intervalle est calculé comme suit : ΔHits / (ΔHits + ΔMisses) × 100. Le symbole Δ représente la différence correspondante. Si les deux différences sont nulles, aucune recherche n'a été comptabilisée dans cette fenêtre ; le taux n'est alors pas défini, au lieu d'être égal à zéro pour cent.

Exemple de calcul à titre indicatif, et non une mesure : si le nombre de « hits » augmente de 900 et celui des « misses » de 100, on obtient 90 % sur un total de 1 000 requêtes comptabilisées. Cela ne signifie ni que les pages sont 90 % plus rapides, ni qu’exactement 900 requêtes à la base de données ont été économisées. Redis compte les recherches de clés ; leur importance pour l’application dépend de l’accès concerné.

Si l'un des compteurs recule entre deux relevés, la simple différence calculée à l'aide de cette fraction n'est pas valable. Un redémarrage ou une réinitialisation des statistiques peut en être la cause. Recommencez la fenêtre de mesure ou divisez-la au niveau de la rupture à l'aide de données d'exploitation fiables, au lieu d'utiliser une valeur négative dans la formule.

S'il y a plusieurs nœuds, tu calcules d'abord les écarts pour chaque nœud concerné sur la même période. Tu additionnes ensuite séparément les « hits » et les « misses », puis tu en déduis le taux global. Une moyenne non pondérée des différents pourcentages traite un nœud comportant peu de recherches de la même manière qu'un nœud comportant beaucoup de recherches, ce qui peut considérablement fausser le tableau d'ensemble.

Notez bien quels nœuds sont effectivement pris en compte et quel rôle ils jouent dans l'environnement. Un taux global ainsi calculé ne décrit que les compteurs sélectionnés et leurs utilisateurs ; il ne correspond pas à lui seul à un taux spécifique du cache d'objets WordPress.

Rapport de mesure et indicateurs Redis

Outre les succès et les échecs, d'autres indicateurs Redis aident à situer les résultats. Là encore, les écarts observés sur la période choisie sont plus révélateurs que les totaux pris isolément. Le tableau suivant fait la distinction entre la signification des valeurs et les conclusions qu'elles ne permettent pas à elles seules de tirer.

Une hausse de expired_keys peut inciter à examiner de plus près les durées de vie et les modèles d'accès. Il ne permet toutefois pas de savoir si une entrée a été à nouveau nécessaire peu après son expiration. De même, evicted_keys à considérer dans le contexte de la limite de mémoire configurée et de la stratégie d'éviction, plutôt que d'en déduire immédiatement une augmentation de la mémoire.

Un outil utile Procès-verbal de mesure Indiquez le début et la fin de la plage horaire, l'instance ou le nœud, les deux différences de compteurs, leur somme et le ratio calculé. Précisez si l'instance est partagée et si un redémarrage ou une réinitialisation a eu lieu pendant cette plage horaire. Cela permettra de retracer les mesures ultérieurement.

Enregistrez en parallèle le type de requête considéré et un indicateur de latence adapté, ainsi que la charge de la base de données et le taux d'erreur. Distinguez par exemple les consultations de pages publiques des requêtes des utilisateurs connectés, si vous disposez de données pertinentes à cet effet. Le taux Redis à lui seul ne permet pas de déterminer lequel de ces types de requêtes a bénéficié d'un résultat pertinent.

Pour permettre une comparaison ultérieure, la période, les nœuds et la composition des requêtes doivent être aussi similaires que possible. Notez également les changements pertinents et les phases de « warm-up » identifiables. Lorsque des données manquent ou qu'une instance partagée ne permet pas d'affectation, cette restriction doit être mentionnée dans le rapport plutôt que d'aboutir à une conclusion apparemment précise.

Lancement à froid, boutique en ligne et site web statique

Après un redémarrage ou un déploiement, certaines entrées nécessaires peuvent dans un premier temps faire défaut. De telles erreurs sont normales lors du remplissage du cache ; le taux de réussite peut ensuite augmenter à mesure que les accès se multiplient. Les valeurs issues de la Phase froide et phase chaude tu devrais les considérer séparément, afin qu'une moyenne sur une longue période ne masque ni les coûts de démarrage ni l'évolution ultérieure.

Dans le cas d'une boutique en ligne ou d'un espace réservé aux utilisateurs connectés, les requêtes dynamiques présentent un intérêt particulier : un cache de page ne répond pas nécessairement à chaque consultation du panier ou du compte. Comparez donc des types de requêtes aussi similaires que possible et surveillez, outre le taux de réussite, leurs temps de réponse et la charge sur la base de données. Un taux de réussite Redis élevé ne signifie pas en soi que le panier s'affiche rapidement et avec un contenu correct.

En revanche, dans le cas d'un site web essentiellement statique, une grande partie des pages consultées peut déjà provenir du cache de pages. Un cache d'objets persistant agit alors principalement sur les requêtes que WordPress traite réellement. Il convient donc d'évaluer séparément si ces requêtes restantes en bénéficient et si l'effet se répercute sur l'ensemble du site web.

Si vous utilisez Redis conjointement avec d'autres sites web ou applications, les compteurs d'instances incluent également leurs accès. Sans télémétrie distincte et adaptée, il est impossible d'attribuer de manière fiable le quota global à un site web en particulier. Note également quels nœuds sont pris en compte : sinon, une variation du quota peut tout aussi bien être due à une autre utilisation ou à une modification de la plage de mesure.

Analyser les valeurs anormales et les erreurs

Un faible taux est avant tout une observation, et non un diagnostic. Un nombre élevé de premières requêtes, des durées de vie courtes ou une répartition des accès avec des clés rarement réutilisées peuvent expliquer ce phénomène. Vérifie si la composition des requêtes ou la fenêtre de mesure a changé avant de modifier les paramètres de mémoire ou de cache.

Les compteurs expired_keys et evicted_keys fournissent des indications supplémentaires : le premier compte les clés expirées, le second les clés évincées en raison de la limite de mémoire. Leurs différences sont propres à l'instance Redis et doivent correspondre à la configuration et à l'utilisation. Un grand nombre de clés expirées ne prouve ni qu’un TTL a été mal choisi, ni qu’une durée de vie plus longue soit judicieuse ; cela peut nuire à l’actualité des données stockées.

Pour vos propres extensions, dans wp_cache_get le paramètre $found Important : il fait la distinction entre une valeur trouvée et une valeur enregistrée false d'une entrée introuvable. Avant d'effectuer des actions liées à un groupe, tu devrais utiliser wp_cache_supports vérifier si le backend concerné prend en charge la fonctionnalité souhaitée. Une solution de remplacement « drop-in » peut différer de l'implémentation du noyau.

Avertissement : Un vidage de cache imprudent peut affecter davantage d'entrées ou d'applications que prévu et fausser la mesure suivante en provoquant un démarrage à froid. Vérifie la portée et obtiens une autorisation avant d'effectuer des actions de suppression. Autres pistes à explorer concernant la Dépannage d'un cache d'objets WordPress lent permettre d'intégrer également dans l'analyse l'éventuelle surcharge liée au cache.

Définir soi-même des valeurs cibles pertinentes

Un quota minimum universel de 90 % ne constitue pas une exigence technique solide. Il serait plus judicieux de prévoir un fourchette cible spécifique au site, qui corresponde à la répartition prévue du trafic et aux besoins de l'application. Redis recommande d'évaluer le taux observé en tenant compte du profil de trafic concerné ; un pourcentage pris isolément ne suffit pas à expliquer les performances de WordPress.

Commencez par enregistrer une mesure de référence représentative, en précisant la période, la plage de mesure, le nombre d'accès et le taux. Pour ce faire, notez les temps de réponse des principaux types de requêtes, la charge de la base de données et le taux d'erreur. Signalez séparément les démarrages à froid et tenez compte des différences typiques entre les périodes de faible et de forte activité, au lieu de considérer une fenêtre aléatoire favorable comme un état normal.

Prévoyez ensuite une modification concrète et, une fois celle-ci validée, testez-la si possible d'abord dans un environnement de test adapté. Comparez ensuite des périodes et des combinaisons de requêtes similaires : le quota et le nombre de requêtes changent-ils, mais aussi la latence ou la charge de la base de données ? Cela permet de mieux distinguer l’effet d’un simple décalage des accès.

Même un taux élevé peut masquer quelques erreurs particulièrement coûteuses. À l'inverse, un taux modéré ne pose pas nécessairement de problème si les requêtes pertinentes reçoivent une réponse rapide et correcte. Les coûts d'exploitation supplémentaires liés à Redis ou à un autre backend persistant ne sont pas automatiquement justifiés par un meilleur taux à lui seul ; tenez compte de l'assistance technique de l'hébergeur, des coûts et des scénarios de panne possibles.