Redis pour le cache d’objets WordPress sur un VPS

Fonctionnement d’un cache d’objets Redis pour WordPress

Un cache d’objets Redis pour WordPress stocke en mémoire les résultats des requêtes à la base de données. La requête suivante les lit alors depuis Redis au lieu de les redemander à MySQL. WordPress inclut déjà un cache d’objets dans son core, WP_Object_Cache, mais celui-ci reste en mémoire PHP et est supprimé à la fin de la requête. Un fichier drop-in le remplace par un cache qui communique avec Redis. Le cache est ainsi conservé d’une requête à l’autre.

Le cache d’objets n’est pas un cache de pages. Cette différence détermine si ce guide vous sera utile. Un cache de pages stocke le HTML final d’une URL et le ressert sans exécuter PHP. C’est plus rapide que tout ce que Redis peut faire et cela fonctionne pour les visiteurs qui ne sont pas connectés. Dès qu’un utilisateur se connecte, ajoute un article à un panier ou ouvre l’interface d’administration, le cache de pages ne s’applique plus et WordPress exécute toute la requête : bootstrap, plugins et requêtes. Un cache d’objets réduit le coût de cette requête. Il sert pour le trafic qu’un cache de pages ne peut pas traiter : sessions des utilisateurs connectés, paniers, paiement et wp-admin. Sur une boutique WooCommerce, cela représente la majeure partie du trafic coûteux.

Les deux mécanismes sont complémentaires. Sur un site très fréquenté, vous devez utiliser les deux. Identifiez clairement le problème que vous cherchez à résoudre. Un site vitrine consulté par des visiteurs anonymes tire presque toute sa rapidité d’un cache de pages. Ajouter Redis change alors très peu de choses.

Une limite à connaître avant de commencer : un cache d’objets ne rend pas une requête lente plus rapide. Il évite de répéter une requête qui a déjà été exécutée. La première requête après une absence dans le cache paie le coût complet. Un plugin qui exécute une requête sans index l’exécute donc une fois par durée de vie du cache.

Ce dont vous avez besoin

• Un VPS Linux avec un shell et sudo. Aucun panneau de contrôle n’est nécessaire.
• WordPress servi par PHP-FPM, par exemple avec une stack LAMP sur Ubuntu 24.04.
• WP-CLI sur le serveur. Chaque étape présentée ici a un équivalent dans l’interface d’administration, mais la version shell est plus rapide.
• Redis sur la même machine que PHP. La faible latence est l’objectif principal, et un saut réseau l’annule.

Les commandes ci-dessous sont prévues pour Ubuntu 24.04 avec PHP 8.3 et l’utilisateur web www-data. Adaptez la version de PHP et l’utilisateur à votre serveur. Exécutez les commandes wp depuis le répertoire de WordPress, celui qui contient wp-config.php.

Installer Redis et l’extension PHP

sudo apt update
sudo apt install -y redis-server php-redis
sudo systemctl enable --now redis-server
redis-cli ping

redis-cli ping doit répondre PONG. Si la commande affiche Could not connect to Redis at 127.0.0.1:6379: Connection refused, le serveur n’est pas démarré. Consultez donc systemctl status redis-server avant de continuer.

php-redis correspond à PhpRedis, l’extension C de PECL. Elle est plus rapide que Predis, qui est entièrement écrit en PHP. Le plugin l’utilise automatiquement lorsqu’elle est présente. PHP-FPM charge les extensions au démarrage. Une nouvelle extension reste donc invisible jusqu’au redémarrage du pool.

sudo systemctl restart php8.3-fpm
php -m | grep redis

Soyez attentif à cette dernière vérification : php -m affiche les modules du PHP utilisé en ligne de commande, et FPM peut charger un ensemble différent. La vérification de référence est celle fournie par les diagnostics du plugin, plus bas.

En août 2026, Ubuntu 24.04 fournit Redis 7.0.15, ce qui convient pour un cache d’objets. Si vous préférez une version plus récente, Redis publie son propre dépôt APT.

sudo apt install -y lsb-release curl gpg
curl -fsSL https://packages.redis.io/gpg | sudo gpg --dearmor -o /usr/share/keyrings/redis-archive-keyring.gpg
sudo chmod 644 /usr/share/keyrings/redis-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/redis-archive-keyring.gpg] https://packages.redis.io/deb $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/redis.list
sudo apt update
sudo apt install -y redis

Si votre distribution fournit Valkey, le fork créé après le changement de licence de 2024, il utilise le même protocole et tout ce qui suit s’applique sans modification.

Liez Redis afin qu’aucun autre accès ne soit possible

Redis n’a pas de mot de passe par défaut. Tout ce qui peut ouvrir une connexion sur le port 6379 peut lire chaque valeur mise en cache et exécuter FLUSHALL. Les instances exposées sur Internet sont détectées par les scanners en quelques heures. La configuration réseau doit donc être traitée avant l’optimisation.

Ouvrez /etc/redis/redis.conf et vérifiez ces lignes :

bind 127.0.0.1 -::1
protected-mode yes

Vérifiez ensuite ce qui est réellement en écoute. Le fichier de configuration est une déclaration, tandis que ss fournit la preuve.

sudo ss -lntp | grep 6379

127.0.0.1:6379 correspond au résultat attendu. 0.0.0.0:6379 signifie que Redis répond sur l’interface publique. Corrigez la ligne bind, puis redémarrez le service.

Lorsque PHP et Redis sont installés sur le même serveur, un socket Unix est préférable à TCP sur loopback. La pile TCP n’est pas utilisée. L’accès dépend des permissions du fichier, et non d’une règle de firewall que vous pourriez modifier ultérieurement.

unixsocket /run/redis/redis-server.sock
unixsocketperm 770

Le socket appartient à l’utilisateur et au groupe redis. L’utilisateur du serveur web doit donc rejoindre ce groupe.

sudo systemctl restart redis-server
sudo usermod -aG redis www-data
sudo systemctl restart php8.3-fpm
redis-cli -s /run/redis/redis-server.sock ping

Cette commande doit également afficher PONG. Could not connect to Redis at /run/redis/redis-server.sock: Permission denied signifie que le groupe n’a pas été pris en compte. Vérifiez id www-data. N’oubliez pas qu’un processus PHP-FPM en cours d’exécution conserve les groupes qu’il possédait au démarrage. C’est pourquoi le redémarrage figure dans la liste. Laissez TCP activé jusqu’à ce que le socket soit validé. Une faute de frappe pourrait sinon désactiver les deux chemins simultanément.

Quelle quantité de mémoire attribuer à Redis ?

Déduisez ce nombre de votre propre serveur. Sans maxmemory, Redis continue de croître jusqu’à ce que le kernel n’ait plus de mémoire disponible et que l’OOM killer arrête un processus, généralement le plus gros. Sur un serveur WordPress, il s’agit souvent de MySQL. journalctl -k | grep -i "out of memory" affiche cet arrêt après coup, mais le site est déjà indisponible.

Commencez par la quantité totale de RAM, puis soustrayez les besoins des autres services. MySQL ou MariaDB réserve innodb_buffer_pool_size, auxquels s’ajoutent les buffers par connexion. PHP-FPM consomme pm.max_children multiplié par la taille résidente réelle d’un worker, généralement de 64 MB à 128 MB sur un site utilisant beaucoup de plugins. Le kernel et le serveur web ont besoin de quelques centaines de megabytes. La quantité restante constitue votre plafond, et Redis en reçoit une partie.

Mesurez maintenant au lieu d’estimer. Après une journée de trafic réel :

redis-cli info memory | grep -E 'used_memory_human|maxmemory_human|maxmemory_policy'
redis-cli dbsize

Si used_memory_human reste largement inférieur à votre limite, réduisez cette limite et rendez la RAM à MySQL, qui l’utilisera plus efficacement. S’il atteint la limite et que evicted_keys augmente toute la journée, relevez-la. Définissez la valeur dans /etc/redis/redis.conf.

maxmemory 256mb
maxmemory-policy allkeys-lru

redis-cli config set maxmemory 256mb s’applique immédiatement, mais est perdu au prochain redémarrage, comme avec un simple sysctl -w. Modifiez le fichier, puis exécutez sudo systemctl restart redis-server et relisez la valeur. Il est utile de définir une seconde limite : un MemoryMax sur l’unité systemd empêche un Redis mal configuré de mettre le serveur hors service. Définissez cette limite au-dessus de maxmemory, jamais à la même valeur, car une limite cgroup arrête le processus au lieu d’évincer une clé. Si Redis s’exécute dans un conteneur à côté de WordPress, utilisez la même valeur dans les limites mémoire de votre fichier Compose, et le même raisonnement permet de choisir entre exécuter la base de données dans Docker ou sur l’hôte.

Choisissez délibérément la politique d’éviction

Une nouvelle instance Redis utilise par défaut noeviction. Vérifiez la vôtre :

redis-cli config get maxmemory-policy

Avec noeviction, une instance pleine cesse d’accepter les écritures et renvoie ceci :

(error) OOM command not allowed when used memory > 'maxmemory'.

Cette seule ligne correspond au pire mode de panne de ce guide, car le site ne devient pas indisponible. Il ralentit. Chaque écriture dans le cache échoue. WordPress revient donc à la base de données pour obtenir la valeur, puis tente de l’enregistrer à nouveau lors de la requête suivante, et échoue encore. Le site doit alors effectuer tout le travail initial sur la base de données, auquel s’ajoute un aller-retour vers Redis pour chaque clé. Rien dans l’interface d’administration WordPress ne vous indique que cela se produit. Cette chaîne apparaît dans le journal d’erreurs PHP. Recherchez donc OOM command not allowed avec grep lorsqu’un site ralentit après l’ajout d’un cache.

allkeys-lru est la valeur par défaut adaptée ici. Lorsque la mémoire manque, Redis supprime la clé utilisée depuis le plus longtemps. C’est exactement le comportement attendu pour un cache d’objets, car chaque valeur qu’il contient est une copie de données qui existent toujours dans MySQL. La perte d’une clé coûte une requête. Refuser une écriture coûte toutes les requêtes, à chaque requête, jusqu’à ce que quelqu’un le remarque.

Évitez les politiques volatile-* pour cet usage. Elles ne prennent en compte que les clés qui ont une expiration. Redis indique qu’elles se comportent comme noeviction lorsqu’aucune clé n’en a. WordPress stocke la plupart des entrées du cache d’objets sans TTL. volatile-lru peut donc se remplir et commencer à refuser les écritures sur un cache d’objets. allkeys-lfu constitue une solution acceptable si votre trafic sollicite très souvent un petit ensemble de clés, car cette politique évince les clés selon leur fréquence plutôt que leur ancienneté d’utilisation. Choisissez une politique en connaissance de cause et notez la raison de ce choix.

Persistance : désactivez-la sauf si vous avez une raison de la conserver

Le redis.conf fourni active les snapshots RDB avec des lignes comme save 900 1 et laisse le fichier append-only désactivé. Pour un cache d’objets dédié, les snapshots ne servent à rien. Les données peuvent par définition être régénérées, et un cache restauré depuis un fichier vieux de vingt minutes contient des valeurs obsolètes que WordPress utilisera.

Les snapshots ont également un coût. BGSAVE duplique le processus, et le copy-on-write peut faire augmenter fortement la mémoire utilisée pendant que le processus enfant écrit. Sur un petit VPS, cela apparaît dans le journal Redis :

Can't save in background: fork: Cannot allocate memory

Vous verrez souvent aussi cet avertissement au démarrage. Redis indique ainsi que le fork risque d’échouer ultérieurement :

WARNING overcommit_memory is set to 0! Background save may fail under low memory condition.

Pour désactiver les snapshots, définissez un planning de sauvegarde vide dans /etc/redis/redis.conf, redémarrez Redis, puis vérifiez que la valeur est bien redevenue vide.

save ""

sudo systemctl restart redis-server
redis-cli config get save

Conservez la persistance uniquement si la même instance contient des données que vous ne pouvez pas reconstruire, comme une file de tâches ou des compteurs de limitation de débit. Dans ce cas, séparez les deux usages. Un cache doit pouvoir évincer ses clés, tandis que les données durables doivent conserver les leurs. maxmemory et l’éviction s’appliquent à toute l’instance, pas à un index de base de données particulier. Deux instances sur deux sockets constituent la solution la plus propre.

Installer le plugin et comprendre le drop-in

wp plugin install redis-cache --activate
wp redis enable
wp redis status

wp redis enable affiche Object cache enabled. en cas de réussite. En réalité, il copie wp-content/plugins/redis-cache/includes/object-cache.php vers wp-content/object-cache.php. Cette copie est le drop-in, et c’est lui qui effectue le travail. WordPress charge wp-content/object-cache.php très tôt, avant l’exécution du code des plugins. Le cache est ainsi disponible pour toute la requête. Un plugin actif sans drop-in en place ne met rien en cache.

Les messages d’échec indiquent quelle partie a échoué. Object cache could not be enabled. signifie que la copie a échoué : wp-content n’est donc pas accessible en écriture pour l’utilisateur qui exécute WP-CLI. A foreign object cache drop-in was found. signifie qu’un autre plugin de cache utilise déjà ce nom de fichier. La correction consiste à utiliser wp redis update-dropin. Si un message se termine par Redis server is unreachable:, suivi de l’erreur du client, les paramètres de connexion sont incorrects. Revenez à redis-cli ping.

Si la copie a échoué à cause des permissions, placez le fichier manuellement et attribuez-le à l’utilisateur du serveur web.

cp wp-content/plugins/redis-cache/includes/object-cache.php wp-content/object-cache.php
sudo chown www-data:www-data wp-content/object-cache.php

La suppression du plugin ne supprime pas le drop-in. Exécutez d’abord wp redis disable : la commande affiche Object cache disabled. et supprime le fichier. Si vous supprimez le répertoire du plugin tout en laissant le drop-in en place, le site continue d’exécuter l’ancien code de cache, sans plugin permettant de le mettre à jour.

Paramètres de connexion dans wp-config.php

Ajoutez-les au-dessus de la ligne contenant /* That's all, stop editing! */, car les constantes définies après cette ligne sont prises en compte trop tard.

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_REDIS_PREFIX', 'shop_prod:' );

Pour le socket Unix, définissez le schéma et le chemin. L’hôte et le port sont alors ignorés.

define( 'WP_REDIS_SCHEME', 'unix' );
define( 'WP_REDIS_PATH', '/run/redis/redis-server.sock' );
define( 'WP_REDIS_PREFIX', 'shop_prod:' );

WP_REDIS_MAXTTL impose une expiration à chaque clé, en secondes. Cette option n’est pas nécessaire avec allkeys-lru. Elle est utile si vous voulez définir une limite supérieure stricte à l’ancienneté d’une valeur mise en cache.

Un Redis, plusieurs sites : préfixes et bases de données

Redis fournit par défaut seize bases de données numérotées, avec un espace de clés distinct dans chacune. Deux installations WordPress utilisant la base de données 0 sans préfixe écrivent les mêmes noms de clés dans le même espace. Un site peut donc lire les options de l’autre et les utiliser. Attribuez un préfixe propre à chaque site.

define( 'WP_REDIS_PREFIX', 'shopA_prod:' );
define( 'WP_REDIS_DATABASE', 1 );

Le préfixe sépare les noms de clés. L’index de base de données sépare les espaces de clés, ce qui est important lors d’un flush : vider un index ne modifie pas les autres. Le plugin documente également WP_REDIS_SELECTIVE_FLUSH, qui supprime uniquement les clés correspondant à votre préfixe, et non toute la base de données, au prix d’un scan pour les trouver.

Les préfixes et les index ne séparent pas la mémoire. maxmemory et la eviction policy s’appliquent à l’ensemble de l’instance. Un site très actif peut donc faire évincer les clés d’un site peu sollicité, sans qu’aucun des deux ne le signale. Les sites qui ne doivent pas s’influencer mutuellement nécessitent des instances Redis distinctes, chacune avec son propre socket et sa propre limite.

Le cache de production ne doit pas être partagé avec la préproduction

Un site de préproduction est généralement une copie des fichiers et de la base de données de production. Il s’agit donc d’une copie de wp-config.php qui utilise le même préfixe et le même index de base de données. Si vous le reliez au même Redis, il écrit les clés de production avec des valeurs de préproduction. Un prix de test ou une option modifiée peut alors apparaître sur le site en ligne, sans déploiement ni trace.

Utilisez un salt différent pour chaque environnement. Dans le wp-config.php de la préproduction :

define( 'WP_REDIS_PREFIX', 'shop_staging:' );
define( 'WP_REDIS_DATABASE', 5 );

Mieux encore, utilisez une instance Redis dédiée pour la préproduction, ou désactivez complètement le object cache. define( 'WP_REDIS_DISABLED', true ); désactive le cache à l’exécution tout en conservant le drop-in. C’est également le moyen le plus rapide de vérifier si un bug est lié au cache.

Les anciens tutoriels utilisent WP_CACHE_KEY_SALT pour cela. Le readme du plugin indique que cette constante est obsolète et remplacée par WP_REDIS_PREFIX. Utilisez donc le nouveau nom.

Vérifiez-le au lieu de lui faire confiance

Commencez par les diagnostics du plugin.

wp redis status

La ligne la plus importante est Drop-in. Drop-in: Valid signifie que WordPress charge le fichier de ce plugin. Drop-in: Not installed signifie que la copie n’a jamais été effectuée et que le site ne dispose d’aucun cache persistant, même si l’interface d’administration affiche un état satisfaisant. Status indique la connexion et Client nomme l’extension utilisée. C’est ici que vous confirmez l’utilisation de PhpRedis plutôt que de Predis.

Interrogez ensuite directement le cœur de WordPress, car il ne tient pas compte de ce que pense le plugin.

wp eval 'var_dump( wp_using_ext_object_cache() );'

bool(true) signifie que le cœur communique avec un cache d’objets externe.

Vérifiez ensuite que des clés arrivent, avec le préfixe que vous avez configuré.

redis-cli -n 0 dbsize
redis-cli -n 0 --scan --pattern 'shop_prod:*' | head

La hausse de dbsize lorsque vous naviguez sur le site constitue la preuve. Zéro clé avec un drop-in valide signifie que la connexion échoue silencieusement ou que le préfixe n’est pas celui que vous pensez.

Enfin, consultez les mesures fournies par Redis.

redis-cli info stats | grep -E 'keyspace_hits|keyspace_misses|evicted_keys|expired_keys'

Le taux de succès est keyspace_hits / (keyspace_hits + keyspace_misses), et la documentation de Redis donne cette formule. Interprétez-le avec deux précautions. Les compteurs couvrent toute l’instance depuis son dernier redémarrage. Ils mélangent donc tous les sites et toutes les applications qui la partagent. De plus, le ratio juste après un flush ou un redémarrage n’a aucune signification, car le cache est encore en cours de remplissage. Laissez-le fonctionner pendant une journée de trafic normale.

Ne comparez pas votre valeur à un taux de succès ou à un nombre de requêtes publié par un hébergeur. Ces chiffres décrivent ses sites et son ensemble de plugins. La valeur importante est la vôtre, mesurée avant et après sur une page qu’un page cache ne peut pas servir.

curl -o /dev/null -s -w '%{time_starttransfer}\n' -b cookies.txt https://example.com/my-account/

Exécutez cette commande plusieurs fois avec un cookie jar contenant une session connectée, avec le cache désactivé (WP_REDIS_DISABLED), puis activé. Cette différence constitue votre résultat.

Quand Redis ralentit WordPress

Une instance complète avec une mauvaise policy est le principal problème, déjà présenté plus haut : OOM command not allowed when used memory > 'maxmemory'. dans le journal, et un site qui paie à la fois pour la base de données et pour le cache.

Le deuxième problème est d’utiliser Redis sur un autre hôte. WordPress effectue des centaines d’appels au cache d’objets pour une seule requête. Si une requête effectue 500 appels et que chaque aller-retour coûte 1 ms, cela représente une demi-seconde d’attente qu’un socket local n’aurait pas ajoutée. Gardez Redis sur le même serveur, ou sur un réseau privé avec une latence inférieure à la milliseconde.

Une table d’options autoloaded trop volumineuse est le troisième problème. Il est fréquent sur les anciens sites. WordPress met en cache toutes les options autoloaded sous la forme d’une seule clé. Un mégaoctet d’options traverse donc la connexion à chaque requête. Mesurez sa taille :

wp db query "SELECT ROUND(SUM(LENGTH(option_value))/1024) AS kb FROM wp_options WHERE autoload IN ('yes','on','auto','auto-on');"

WordPress 6.6 a ajouté de nouvelles valeurs pour autoload. Une ancienne requête qui recherche uniquement 'yes' sous-estime donc la taille sur une installation récente. Au-delà d’un mégaoctet, le problème doit être corrigé dans la table d’options, pas dans Redis.

Un redémarrage vide entièrement le cache. Les minutes qui suivent systemctl restart redis-server correspondent donc uniquement à des cache misses et à des accès à la base de données. Redémarrez lorsque le trafic est faible. Par ailleurs, un cache d’objets n’empêche pas wp-cron.php de s’exécuter lors du chargement des pages par les visiteurs. C’est une autre source de requêtes lentes : déplacez WP-Cron vers une vraie tâche cron système pendant que vous y êtes.

Entretien

Videz les caches après un déploiement qui modifie les options ou le code du thème avec wp cache flush. Exécutez wp redis update-dropin après la mise à jour d’une extension si le drop-in ne s’est pas mis à jour automatiquement : un drop-in provenant d’une ancienne version de l’extension et utilisé avec une version plus récente est une cause réelle de comportements anormaux. Surveillez un serveur en production avec redis-cli --stat, qui affiche une ligne par seconde. redis-cli monitor affiche chaque commande et consomme réellement du CPU sur une instance très sollicitée. Utilisez-le donc pendant quelques secondes pour reproduire un problème, puis arrêtez-le.

Un dernier chiffre mérite d’être connu : redis-cli info clients indique connected_clients. PHP-FPM maintient une connexion par worker. Cette valeur doit donc suivre votre pm.max_children, et non le dépasser d’un ordre de grandeur. Si c’est le cas, un processus ouvre des connexions sans les fermer.

FAQ

Ai-je encore besoin d’un cache de pages si j’utilise un cache d’objets Redis ?

Oui, pour le trafic anonyme. Un cache de pages sert du HTML stocké sans exécuter PHP, ce qui coûte toujours moins cher que d’exécuter WordPress avec un cache d’objets déjà chaud. Le cache d’objets prend en charge les requêtes qu’un cache de pages doit ignorer : utilisateurs connectés, paniers, paiement et wp-admin. Sur une boutique ou un site d’adhésion, les deux sont utiles. Sur un site dont les visiteurs ne se connectent jamais, le cache de pages effectue presque tout le travail.

Quelle quantité de mémoire dois-je attribuer à Redis pour WordPress ?

Calculez-la à partir de votre propre serveur au lieu de reprendre une valeur toute faite. Prenez la RAM totale, soustrayez le buffer pool MySQL et les buffers par connexion, soustrayez pm.max_children multiplié par la taille résidente d’un worker PHP-FPM, puis soustrayez quelques centaines de mégaoctets pour le kernel et le serveur web. Attribuez à Redis une partie de ce qui reste, puis vérifiez used_memory_human dans redis-cli info memory après une journée de trafic et ajustez la valeur. Un site WordPress seul se stabilise généralement à quelques dizaines de mégaoctets. Un maxmemory de 256 MB constitue donc un point de départ généreux sur un serveur de 4 GB.

Pourquoi mon site est-il devenu plus lent après l’activation du cache d’objets Redis ?

La cause habituelle est une instance pleine qui utilise la stratégie noeviction. Redis refuse les nouvelles écritures et renvoie OOM command not allowed when used memory > 'maxmemory'.. WordPress revient alors à la base de données pour chaque valeur et subit en plus un aller-retour Redis inutile. Vérifiez redis-cli config get maxmemory-policy, définissez allkeys-lru et confirmez que maxmemory n’est pas trop faible. Les autres causes fréquentes sont un serveur Redis distant, car des centaines d’allers-retours par requête finissent par s’accumuler, et une valeur d’options chargée automatiquement de plusieurs mégaoctets, qui transite par la connexion à chaque requête.

Plusieurs sites WordPress peuvent-ils partager un même serveur Redis ?

Oui, avec certaines précautions. Attribuez à chaque site un WP_REDIS_PREFIX unique afin d’éviter les collisions entre les noms de clés, ainsi qu’un index WP_REDIS_DATABASE distinct pour que la purge d’un site ne vide pas celui des autres. Ils partagent toutefois la mémoire : maxmemory et l’éviction s’appliquent à l’ensemble de l’instance. Un site très actif peut donc évincer les clés d’un site peu actif. Les sites qui ne doivent pas s’influencer mutuellement nécessitent des instances Redis distinctes, avec leurs propres limites.

Est-il sûr de supprimer wp-content/object-cache.php ?

Oui. Il s’agit d’un drop-in, pas d’un composant du cœur de WordPress. Sa suppression ramène WordPress à son cache intégré par requête. Le site continue de fonctionner et effectue simplement davantage de requêtes vers la base de données. Préférez wp redis disable, qui supprime proprement le fichier et indique Object cache disabled.. La suppression manuelle est la bonne mesure d’urgence si Redis est indisponible ou fonctionne mal et que vous ne pouvez pas accéder à l’interface d’administration.