Configurer Redis comme cache d’objets WordPress sur VPS

Ce que fait un cache d’objets Redis pour WordPress

Un cache d’objets Redis pour WordPress stocke en mémoire les résultats des requêtes vers la base de données. La requête suivante les lit alors depuis Redis au lieu d’interroger MySQL à nouveau. WordPress intègre déjà un cache d’objets dans son core, WP_Object_Cache, mais celui-ci réside dans la 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.

La mise en cache des objets n’est pas la mise en cache des 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. Cette méthode est plus rapide que tout ce que Redis peut faire et fonctionne pour les visiteurs qui ne sont pas connectés. Dès qu’un utilisateur se connecte, ajoute un article au panier ou ouvre l’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 et sont tous les deux utiles sur un site très fréquenté. Identifiez clairement le problème que vous cherchez à résoudre. Un site vitrine consulté par des visiteurs anonymes tire presque toute sa vitesse d’un cache de pages. Ajouter Redis change alors très peu les performances.

Une limite importante 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 qu’il vous faut d’abord

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

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 WordPress contenant 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, et le plugin l’utilise automatiquement lorsqu’elle est présente. PHP-FPM charge les extensions au démarrage. Une nouvelle extension n’est donc pas prise en compte tant que vous n’avez pas redémarré le pool.

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

Soyez attentif à cette dernière vérification : php -m liste les modules du PHP de la ligne de commande, et FPM peut charger un ensemble différent. La vérification déterminante est celle des 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.

Lier Redis afin qu’aucun autre hôte ne puisse y accéder

Redis n’a pas de mot de passe par défaut. Tout ce qui peut ouvrir une connexion vers le port 6379 peut lire toutes les valeurs mises en cache et exécuter FLUSHALL. Les instances exposées à Internet sont découvertes par les scanners en quelques heures. Le paramètre réseau doit donc être configuré 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, car le fichier de configuration est une déclaration et ss en 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 se trouvent sur le même serveur, un socket Unix est préférable à TCP sur loopback. La pile TCP n’intervient pas. L’accès dépend des permissions du fichier, plutôt que 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é. Sinon, une faute de frappe pourrait désactiver les deux chemins d’accès simultanément.

Quelle quantité de mémoire attribuer à Redis ?

Déterminez cette valeur à partir de votre propre serveur. Redis sans maxmemory continue de croître jusqu’à ce que le noyau n’ait plus de mémoire et que l’OOM killer termine 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 ce kill a posteriori, mais le site est déjà hors service.

Partez de la quantité totale de RAM et 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 entre 64 MB et 128 MB sur un site chargé en extensions. Le noyau et le serveur web ont besoin de quelques centaines de mégaoctets. La mémoire 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. Si Redis atteint la limite et que evicted_keys augmente toute la journée, augmentez-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. C’est le même piège qu’avec un sysctl -w seul. Modifiez le fichier, puis sudo systemctl restart redis-server, et relisez ensuite la valeur. Il est utile d’ajouter une deuxième limite : un MemoryMax sur l’unité systemd empêche un Redis mal configuré de mettre le serveur hors service. Définissez-la au-dessus de maxmemory, jamais à la même valeur, car une limite cgroup tue 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 de mémoire de votre fichier Compose, et le même raisonnement guide le choix 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 instance Redis fraîchement installée utilise par défaut noeviction. Vérifiez la vôtre :

redis-cli config get maxmemory-policy

Avec noeviction, une instance saturée 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 tombe pas. Il ralentit. Chaque écriture dans le cache échoue. WordPress revient donc à la base de données pour récupérer la valeur, puis tente de la stocker à nouveau à la requête suivante et échoue encore. Le site cumule alors tout le travail initial effectué par la base de données et un aller-retour vers Redis pour chaque clé. Rien dans l’administration WordPress ne vous indique que cela se produit. La 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 le bon choix par défaut ici. Lorsque la mémoire manque, Redis supprime la clé la moins récemment utilisée. C’est exactement ce que l’on attend d’un object cache, 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 s’en aperçoive.

Évitez les politiques volatile-* pour cet usage. Elles ne prennent en compte que les clés auxquelles une expiration est associée. Redis indique qu’elles se comportent comme noeviction lorsqu’aucune clé n’en possède. WordPress stocke la plupart des entrées de l’object cache sans TTL. Par conséquent, volatile-lru peut se remplir et commencer à refuser les écritures sur un object cache. allkeys-lfu est une solution acceptable si le trafic concerne 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é. Choisissez une politique en connaissance de cause et notez la raison de ce choix.

Persistance : désactivez-la sauf si vous en avez besoin

Le redis.conf fourni active les instantanés RDB avec des lignes comme save 900 1 et désactive le fichier append-only. Pour un cache d’objets pur, les instantanés n’apportent 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 comme si elles étaient valides.

Les instantanés ont également un coût. BGSAVE duplique le processus, et le mécanisme copy-on-write peut faire augmenter fortement la consommation mémoire pendant l’écriture du processus enfant. 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 instantanés, définissez un calendrier de sauvegarde vide dans /etc/redis/redis.conf, redémarrez, puis vérifiez que la valeur est 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 impossibles à 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 des clés, tandis que les données durables doivent conserver les leurs. Or maxmemory et l’éviction s’appliquent à toute l’instance, et non à 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’erreur 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 par 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-la manuellement et attribuez-la à 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, qui affiche Object cache disabled. et supprime le fichier. Si vous supprimez le répertoire du plugin en laissant le drop-in en place, le site continue d’utiliser l’ancien code de cache, sans plugin pour le mettre à jour.

Paramètres de connexion dans wp-config.php

Ajoutez-les au-dessus de la ligne /* 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 pour chaque clé, en secondes. Vous n’en avez pas besoin avec allkeys-lru. Cette option est utile si vous voulez définir une limite 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 configurées sur 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 à chaque site son propre préfixe.

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. Cela 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, au lieu de vider toute la base de données, mais doit les rechercher au préalable.

Les préfixes et les index ne séparent pas la mémoire. maxmemory et la stratégie d’éviction s’appliquent à toute l’instance. Un site très sollicité peut donc faire évincer les clés d’un site peu actif, 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.

Éviter que la préproduction utilise le cache de la production

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

Attribuez manuellement un sel différent à chaque environnement. Dans le fichier wp-config.php de la préproduction :

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

Mieux encore, utilisez une instance Redis distincte pour la préproduction, ou désactivez complètement le cache d’objets. define( 'WP_REDIS_DISABLED', true ); désactive le cache à l’exécution et laisse le drop-in en place. C’est également le moyen le plus rapide de vérifier si un bug vient du cache ou non.

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

Vérifiez au lieu de 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’écran d’administration semble correct. 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 se fie pas aux indications du plugin.

wp eval 'var_dump( wp_using_ext_object_cache() );'

bool(true) signifie que le cœur utilise un object cache externe.

Vérifiez ensuite que les clés arrivent bien, 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 parcourez 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 l’utilisent. De plus, le ratio juste après un flush ou un redémarrage n’a aucune signification, car le cache est encore en train de se remplir. 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 avec un cookie jar contenant une session authentifiée, plusieurs fois, avec le cache désactivé (WP_REDIS_DISABLED), puis activé. Cette différence est votre résultat.

Quand Redis ralentit WordPress

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

Un Redis installé sur un autre hôte est le deuxième problème. 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. Le gain exact apporté par le kernel dans le cas du même serveur est une autre question : la planification tenant compte du cache ajoutée dans Linux 7.2 essaie de maintenir les processus très communicants comme PHP-FPM et Redis sur des cœurs qui partagent un cache, et un invité VPS en bénéficie moins que du bare metal.

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

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 valeur 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 produisent donc uniquement des cache misses et des accès à la base de données. Redémarrez lorsque le trafic est faible. Un object cache n’empêche pas non plus 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.

Maintenance

Après un déploiement qui modifie des options ou le code du thème, videz le cache avec wp cache flush. Exécutez wp redis update-dropin après une mise à jour de plugin si le drop-in ne s’est pas mis à jour automatiquement. Un drop-in provenant d’une ancienne version du plugin et utilisé avec une version plus récente est une source fréquente 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 indicateur mérite d’être connu : redis-cli info clients renvoie connected_clients. PHP-FPM conserve une connexion par worker. Cette valeur doit donc rester proche de votre pm.max_children, et non le dépasser d’un ordre de grandeur. Si ce n’est pas 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 déjà généré sans exécuter PHP. C’est toujours moins coûteux 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 avec espace membres, les deux sont utiles. Sur un site dont les visiteurs ne se connectent jamais, le cache de pages fait 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 quantité totale de RAM, soustrayez le buffer pool MySQL et les buffers par connexion, puis soustrayez pm.max_children multiplié par la taille résidente d’un worker PHP-FPM. Réservez aussi quelques centaines de mégaoctets au kernel et au serveur web. Attribuez à Redis une partie de la mémoire restante, 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 unique utilise 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 ajoute inutilement un aller-retour vers Redis. 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’additionner, et une valeur d’options chargée automatiquement de plusieurs mégaoctets, qui traverse la connexion à chaque requête.

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

Oui, avec les précautions nécessaires. 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 afin que la purge d’un site ne vide pas le cache d’un autre. Ils partagent néanmoins la mémoire : maxmemory et l’éviction s’appliquent à toute 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 sans risque de supprimer wp-content/object-cache.php ?

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