Optimisation drupal : configurer l'invalidation par cache tags avec Redis

Pour les architectures à fort trafic, la gestion du cache applicatif n'est pas une option d'optimisation, c'est une condition de survie. Drupal excelle dans la granularité de son cache grâce au système de Cache Tags, permettant d'invalider précisément les données. Cependant, stocker ces métadonnées dans la base de données relationnelle par défaut (MySQL/MariaDB) devient rapidement un goulot d'étranglement sévère lors des pics de charge.

Déporter ce système vers une base en mémoire comme Redis est indispensable. Toutefois, une simple installation de base ne suffit pas pour un environnement de production. Il faut une maîtrise complète, de l'optimisation du noyau Debian jusqu'à l'invalidation granulaire côté Drupal.

Les limites du cache standard sur les architectures à fort trafic

La base de données relationnelle montre très vite ses limites face aux mécanismes de cache de Drupal :

• Verrous de table lors des purges massives (les fameuses requêtes TRUNCATE ou DELETE)
• Hausse drastique de l'utilisation CPU et des I/O disque sur le serveur SQL
• Temps de latence accru lors du calcul de la validité des dépendances de cache
• Saturation des pools de connexion en cas d'invalidation en cascade

Basculer sur Redis permet de répondre à ces problématiques en conservant la donnée en RAM, garantissant des temps de réponse sous la milliseconde, même lors d'invalidations complexes liées aux cache tags.

Préparation du socle Debian : tuning kernel et systemd

La performance d'un serveur Redis dépend intimement de l'environnement système hôte. Sous Debian, plusieurs ajustements sont nécessaires pour garantir la stabilité et éviter que le processus ne soit tué par l'OOM (Out Of Memory) killer.

Paramétrage avancé via sysctl

Il est impératif d'ajuster la façon dont le noyau Linux gère la mémoire allouée et les connexions réseau pour Redis. Ajoutez ces directives dans votre fichier de configuration sysctl :

# /etc/sysctl.d/99-redis-tuning.conf
vm.overcommit_memory = 1
net.core.somaxconn = 65535

L'activation du paramètre vm.overcommit_memory permet à Redis d'effectuer ses sauvegardes en arrière-plan (BGSAVE) sans échouer si la mémoire libre semble insuffisante au moment du fork. Le second paramètre augmente la file d'attente des connexions entrantes, crucial pour absorber les requêtes concurrentes d'un site Drupal à fort trafic.

Renforcement du service systemd

Par défaut, les limites imposées par systemd peuvent entraver Redis. Il faut créer un fichier d'override pour le démon :

# systemctl edit redis-server
[Service]
LimitNOFILE=65536

Cela empêchera les erreurs de type "Too many open files" lorsque des milliers de requêtes PHP tenteront de lire ou d'invalider des cache tags simultanément.

Configuration de redis pour la gestion des cache tags

Drupal gère les cache tags sous forme de listes d'éléments. La politique d'éviction (la façon dont Redis libère de la mémoire quand il est plein) doit être soigneusement choisie.

Dans le fichier /etc/redis/redis.conf, la configuration suivante est recommandée :

maxmemory 2gb
maxmemory-policy volatile-lru

En choisissant volatile-lru, Redis supprimera en priorité les clés disposant d'un TTL (Time To Live) qui ont été le moins récemment utilisées. C'est le comportement idéal pour un cache Drupal, car il préserve l'intégrité des données permanentes (si vous utilisez Redis pour d'autres microservices sur la même machine) tout en purgeant intelligemment les caches expirés.

Intégration côté Drupal : paramétrage du fichier settings.php

Une fois le module Redis installé et activé via Composer, l'essentiel de la configuration s'effectue au niveau de l'infrastructure logicielle, dans le fichier settings.php. Voici une configuration optimisée pour la performance brute :

$settings['redis.connection']['interface'] = 'PhpRedis';
$settings['redis.connection']['host']      = '127.0.0.1';
$settings['redis.connection']['port']      = '6379';
$settings['redis.connection']['base']      = 0;

$settings['cache']['default'] = 'cache.backend.redis';
$settings['cache_prefix'] = 'drupal_prod_';

// optimisation specifique pour les cache tags
$settings['redis_compress_length'] = 100;
$settings['redis_compress_level'] = 1;

L'utilisation de l'extension PHP native PhpRedis est indispensable pour les architectures exigeantes, car elle est compilée en C et nettement plus performante que les alternatives basées sur des classes PHP (comme Predis). La compression est ici légèrement activée pour soulager la bande passante réseau si votre serveur Redis est distant, tout en consommant un minimum de CPU.

Autre optimisation, l'utilisation d'un socket Unix au lieu du protocole TCP (127.0.0.1:6379) élimine la surcharge de la pile réseau locale : c'est un gain de latence indispensable si PHP et le démon Redis cohabitent sur la même machine. Il faut simplement s'assurer que l'utilisateur système exécutant PHP a les droits de lecture/écriture sur ce fichier .sock.

$settings['redis.connection']['interface'] = 'PhpRedis';
$settings['redis.connection']['host']      = '/var/run/redis/redis.sock';
$settings['redis.connection']['port']      = NULL;

Optimisation de Redis (redis.conf)

La désactivation totale de la persistance avec save "" et appendonly no est vitale : un cache applicatif n'a pas besoin d'être restauré après un redémarrage. Cela supprime tous les I/O disque inutiles et prévient les blocages liés au fork du processus (BGSAVE). Concernant l'éviction, si l'instance Redis est strictement dédiée au cache, allkeys-lru est légèrement plus performant que volatile-lru : le moteur supprime les anciennes clés sans perdre de temps à vérifier les TTL.

save ""
appendonly no
maxmemory 2gb
maxmemory-policy allkeys-lru

Debug avancé : gestion des caches sur une infrastructure multisite

Le multisite Drupal présente des défis redoutables concernant le cache. Une mauvaise configuration peut amener le site A à invalider les cache tags du site B.

Isolation des données : préfixes vs bases de données

Il existe deux manières d'isoler les environnements sur un serveur Redis :

• L'utilisation de bases de données numérotées (de 0 à 15 par défaut). Séparation nette mais empêche l'utilisation de Redis Cluster.
• L'utilisation de préfixes uniques définis via $settings['cache_prefix']. Idéal pour la scalabilité horizontale.

Pour les architectures destinées à évoluer vers un cluster Redis, la stratégie des préfixes est la seule viable.

Audit et monitoring des invalidations

Lorsque des pages ne se mettent pas à jour, le debug des cache tags nécessite d'inspecter l'activité de Redis en temps réel. Utilisez l'outil en ligne de commande avec précaution :

redis-cli monitor | grep "del"

Cette commande permet de visualiser en direct les requêtes de suppression envoyées par Drupal à Redis, vous aidant à identifier si un événement d'invalidation de tag (par exemple, la sauvegarde d'un nœud) déclenche correctement la purge attendue.

FAQ

Quels sont les prérequis pour utiliser Redis avec Drupal ? 

Il faut disposer d'un serveur Redis accessible, de l'extension PHP phpredis installée sur le serveur web, et du module contribué Drupal "Redis".

Pourquoi mes cache tags ne s'invalident-ils pas correctement en multisite ? 

Cela provient généralement d'un manque d'isolation. Vérifiez que chaque instance de votre architecture multisite possède un préfixe de cache unique défini dans son fichier settings.php respectif.

Faut-il allouer toute la RAM disponible du serveur à Redis ? 

Non. Il est crucial de laisser suffisamment de mémoire vive pour le système d'exploitation et les autres services (comme PHP-FPM ou Nginx). L'utilisation de la directive maxmemory dans la configuration de Redis est obligatoire pour prévenir les crashs liés à un manque de mémoire.