# Isoler les données d’un plugin de sondage du cache d’objets persistant > Un plugin de sondage en direct qui écrit sans cesse dans le cache d'objets peut saturer Redis pour tout le reste du site. Isolation par groupe non persistant. - Auteur : WordPress Développement - Publié le : 2022-12-23 - Mis à jour le : 2022-12-23 - Catégorie : Performance - URL : https://www.wpmoderne.fr/performance/isoler-plugin-sondage-cache-objet-persistant/ ## L’essentiel - Les résultats d'un sondage changent trop vite pour être mis en cache - wp_cache_add_non_persistent_groups évite l'écriture sur le serveur Redis - Le choix du nom de groupe conditionne toute la portée du correctif `wp_cache_add_non_persistent_groups( array( 'sondage_live' ) );` — cette seule ligne, placée au bon endroit, a suffi à faire retomber le taux d'écriture sur le serveur Redis d'un site d'actualité qui diffusait un sondage en direct pendant une soirée électorale. Le symptôme initial était classique : un ralentissement général du site pendant les pics de vote, alors que rien dans le code du sondage lui-même ne semblait anormalement lourd. Le problème ne venait pas du calcul des résultats, mais de leur mise en cache systématique dans un backend d'objets partagé par toutes les fonctionnalités du site. ## Comprendre le comportement par défaut du cache d'objets WordPress dispose d'une API de cache d'objets unifiée, exposée par des fonctions comme `wp_cache_get` et `wp_cache_set`. Sans backend persistant, cette API ne vit que le temps d'une requête PHP : chaque affichage de page repart de zéro. Avec un plugin d'objet cache persistant comme Redis Object Cache, ce même cache est partagé entre toutes les requêtes et survit d'une visite à l'autre. C'est précisément ce comportement qui posait problème ici. Le plugin de sondage stockait le décompte des votes dans le cache d'objets, sous une clé mise à jour à chaque nouveau vote, potentiellement plusieurs fois par seconde en période de pointe. Chaque écriture repartait vers Redis, saturant les connexions disponibles pour des besoins bien plus stables comme le cache de menus ou de requêtes de taxonomie. ## Le correctif par groupe non persistant La fonction `wp_cache_add_non_persistent_groups()` permet de déclarer qu'un groupe de cache donné ne doit jamais transiter par le backend persistant, même si un tel backend est actif. Les appels à `wp_cache_get` et `wp_cache_set` continuent de fonctionner normalement, mais restent cantonnés à la mémoire du processus PHP en cours. ``` L'essentiel à retenir : Les résultats d'un sondage changent trop vite pour être mis en cache ; wp_cache_add_non_persistent_groups évite l'écriture sur le serveur Redis ; Le choix du nom de groupe conditionne toute la portée du correctif ## Vérifier que le correctif porte ses fruits La vérification s'est faite en observant le nombre de commandes Redis via `redis-cli info commandstats`, avant et après l'ajout du groupe non persistant. Les commandes `SET` liées au préfixe du sondage sont tombées à zéro côté Redis, remplacées par de l'écriture purement locale à chaque requête PHP. Il faut noter une contrepartie logique : les données du sondage redeviennent locales à chaque exécution, donc le compteur affiché à l'utilisateur devait de toute façon être recalculé à chaque affichage ou rafraîchi via une requête asynchrone. Rendre ces données non persistantes n'a rien changé côté utilisateur, puisque le plugin ne s'appuyait déjà pas sur une valeur strictement figée entre deux vues. ## Variantes selon le groupe déjà utilisé Tous les plugins ne nomment pas leur groupe de cache aussi clairement. Quand le nom du groupe n'est pas documenté, il reste possible de l'identifier en activant temporairement Query Monitor, qui liste les groupes de cache sollicités sur la page concernée avec leur nombre d'appels. - Groupe dédié et clairement nommé par le plugin : correctif direct via `wp_cache_add_non_persistent_groups` - Groupe générique partagé avec d'autres fonctionnalités (par exemple `options`) : correctif impossible sans modifier le plugin, car cela isolerait aussi des données qui méritent d'être persistées - Absence totale de mise en cache, écriture directe en base à chaque vote : le problème n'est plus le cache d'objets mais la table de la base elle-même, un tout autre chantier ## Un correctif à documenter, pas à généraliser Il est tentant, une fois ce mécanisme découvert, de déclarer non persistants tous les groupes qui semblent bavards. C'est une erreur : un groupe rendu non persistant perd tout l'intérêt du cache d'objets partagé, notamment sur un hébergement à plusieurs serveurs PHP où le cache local à un processus ne profite à aucun autre serveur. > Le bon réflexe consiste à se demander, pour chaque groupe suspect : est-ce que cette donnée a besoin de survivre entre deux requêtes différentes ? Si la réponse est non, la rendre non persistante est un gain net. Si la réponse est oui, le problème est ailleurs. ## En résumé Un plugin qui écrit en continu dans le cache d'objets n'est pas nécessairement mal conçu : il applique simplement l'API telle quelle, sans connaître le contexte de production dans lequel il tourne. C'est à l'intégrateur du site d'ajuster ce comportement via `wp_cache_add_non_persistent_groups`, à condition d'identifier précisément le nom du groupe concerné avant d'agir. Sur ce cas de sondage en direct, la ligne de code a suffi à ramener le site à un fonctionnement normal pendant le pic de trafic suivant.