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.
<?php
add_action( 'plugins_loaded', function () {
wp_cache_add_non_persistent_groups( array( 'sondage_live' ) );
} );
Le plugin de sondage devait bien sûr utiliser ce groupe précis pour ses écritures. Un rapide coup d’œil au code source a confirmé l’usage de wp_cache_set( $cle, $valeur, 'sondage_live' ), ce qui rendait le correctif directement applicable sans toucher au plugin lui-même.
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.
