Redis peut réduire le travail SQL, mais il n’est pas automatiquement bénéfique. Latence réseau, éviction, sérialisation et comportement des plugins peuvent en faire un nouveau goulot.
« Connecté » ne prouve pas que le cache objet est sain. Mesurez taux de hit, latence, pression mémoire et comportement applicatif réel.
1. Vérifier où Redis s’exécute
Socket local, TCP local et Redis distant ont des profils de latence très différents. Un cache distant peut être plus lent que les requêtes SQL qu’il remplace.
2. Contrôler mémoire et politique d’éviction
Des évictions fréquentes donnent une performance irrégulière et suppriment les objets avant qu’ils produisent un bénéfice.
3. Distinguer données périmées et cache de page
Cache objet, cache de page et CDN ne stockent pas la même chose. Videz la couche qui possède réellement la valeur périmée.
4. Rechercher les objets volumineux ou très volatils
Grosses options, transients et clés à fort taux de changement consomment mémoire et temps de sérialisation.
5. Mesurer wp-admin séparément
Le backend révèle souvent des problèmes de cache objet que les benchmarks anonymes du front masquent.
6. Comparer avec et sans Redis
Une mesure A/B contrôlée vaut mieux que des suppositions. Si le chemin mesuré est plus rapide sans cache objet, cherchez la cause avant de le réactiver.