Redis PHP : activer l’extension, choisir les bases et surveiller l’usage

Table des matières :

1. Redis PHP : extension native (phpredis) vs client pur PHP (Predis)
2. Activer l’extension Redis sur PHP 8.1–8.5 : paquets, PECL, conteneurs
3. Choisir les “bases” Redis : DB index, préfixes, ou instances dédiées (et le piège Cluster)
4. Paramétrage Redis côté serveur et options client PHP : ce qui impacte vraiment la prod
5. Surveiller l’usage Redis (mémoire, hit ratio, évictions, latence) : commandes et métriques utiles
6. Intégration concrète avec PrestaShop : sessions, cache applicatif, verrous (et limites du core)
7. Checklist opérationnelle : activer, séparer, valider sous charge

Redis côté serveur ne sert à rien si votre runtime PHP ne sait pas lui parler proprement. Le sujet « Redis PHP » se résume à trois décisions techniques : quel client, quelle stratégie de séparation (bases / préfixes / instances), et comment mesurer l’usage réel (mémoire, latence, évictions, hit ratio). Sur PrestaShop (8.x / 9.x), ça implique souvent de sortir du “core” : l’interface Performance ne sait pas configurer Redis nativement, donc vous devez passer par configuration PHP (sessions), Symfony Cache (modules) ou une couche applicative dédiée.

Un point de méthode utile avant de toucher à quoi que ce soit : clarifiez le rôle de Redis dans votre boutique.

• Cache “jetable” (recalculable) : objets applicatifs, résultats de requêtes, fragments HTML, etc.
• Sessions : données utilisateurs, panier, jetons CSRF (selon implémentation).
• Verrous : anti-concurrence stock/checkout, jobs asynchrones, rate limiting.
• État métier (à éviter si possible dans un PrestaShop standard) : si vous y arrivez, Redis devient une brique critique au même niveau que MySQL.

Cette clarification change vos choix : par exemple, une éviction “acceptable” pour un cache peut être catastrophique pour des sessions ou des verrous.

Redis PHP : extension native (phpredis) vs client pur PHP (Predis)

La “bonne” option en production, c’est quasiment toujours l’extension native phpredis (PECL redis). Elle expose la classe Redis (et RedisCluster) et s’exécute en C, donc avec moins d’allocations PHP, moins de copies mémoire, et une latence plus stable sous charge. À l’inverse, Predis (https://github.com/predis/predis) est une librairie Composer, donc pratique quand vous n’avez pas la main sur le serveur (mutualisé, restrictions cPanel), mais elle coûte plus cher en CPU et en mémoire côté PHP. Sur une boutique qui monte en trafic (FPM workers + checkout + backoffice), la différence se voit vite : plus de GC, plus de temps passé en sérialisation/désérialisation, plus de variance sur le TTFB. Si vous êtes déjà en train d’optimiser OPcache et PHP-FPM, ajouter un client Redis “pur PHP” est souvent un pas en arrière (cf. votre contexte perf global : OPcache PHP : activer et vérifier l’extension dans cPanel et Performance PrestaShop : benchmarks et optimisation PHP-FPM, OPCache, MySQL).

Pour trancher rapidement, une comparaison “terrain” (sans dogme) :

Critère	phpredis (PECL)	Predis (Composer)
Déploiement	nécessite extension côté SAPI (FPM/CLI)	simple composer require
Perf CPU / latence	généralement meilleure	généralement plus variable sous charge
Persistance conn. (pconnect)	oui (attention maxclients)	possible via le runtime, mais moins “natif”
Fonctionnalités Redis (cluster, options bas niveau)	très complet	dépend des versions / abstractions
Mutualisé / cPanel verrouillé	parfois difficile	souvent la seule option

Rappel factuel sur Redis lui-même : selon https://redis.io, Redis est un moteur en mémoire utilisable comme base, cache ou broker. Cette polyvalence est précisément le piège courant : Redis n’est pas “juste un cache” par nature. Selon votre configuration (RDB/AOF, réplication, politiques d’éviction), vous pouvez vous retrouver à utiliser Redis comme système d’état, ce qui impose des exigences de durabilité, de sécurité et de monitoring plus strictes.

Activer l’extension Redis sur PHP 8.1–8.5 : paquets, PECL, conteneurs

Contexte versions (2026) : PrestaShop 9.1 supporte PHP 8.1 à 8.5 (cf. PrestaShop 9.1 : compatibilité PHP 8.1–8.5, CLI et nouveautés développeurs). Sur Debian/Ubuntu, la voie la plus simple est le paquet distro correspondant à votre version de PHP (ne mélangez pas, sinon vous activez l’extension sur la mauvaise SAPI).

Exemples (à adapter) :

# Debian/Ubuntu (PHP-FPM)
sudo apt update
sudo apt install -y php8.3-redis

# redémarrage : choisissez la bonne unité
sudo systemctl restart php8.3-fpm
# si Apache mod_php :
sudo systemctl restart apache2

# validation
php -m | grep -i redis
php --ri redis

Deux vérifications qui évitent des heures de debug :

• CLI vs FPM : php -m valide le CLI… pas votre pool FPM. Pour être sûr côté FPM, regardez le fichier phpinfo() servi via HTTP (en staging), ou inspectez la conf du pool (php-fpm8.3 -tt selon distro) et les conf.d réellement chargés.
• Même version partout : une boutique PrestaShop appelle parfois PHP en CLI (cron, indexation, imports). Assurez-vous que le PHP CLI et le PHP-FPM pointent vers la même version et les mêmes modules si votre code (ou modules) utilise Redis hors requêtes web.

Sur une stack conteneurisée (Docker, DDEV), vous avez deux cas :

1) Image PHP custom : installez via pecl install redis + docker-php-ext-enable redis (sur les images officielles PHP).
2) Runtime imposé : vous basculez sur Predis si vous ne pouvez pas toucher à l’image.

En DDEV, le pattern classique est de builder une image web qui ajoute php-redis (ou pecl redis) puis d’exécuter vos validations depuis le conteneur, comme vous le faites déjà pour Composer (DDEV Composer : exécuter et configurer Composer dans les conteneurs, DDEV : outils développeur intégrés, ddev exec/ssh et extensions d’image). L’objectif : que php --ri redis soit vrai dans l’environnement qui exécute PrestaShop (CLI ET FPM si vous utilisez des cron).

Dernier cas : cPanel / mutualisé. Si vous avez la main via “Select PHP Version”, activez redis côté extensions, mais validez dans le bon handler (FPM / LSAPI / Apache). Les divergences entre CLI et FPM sont un classique : php -m peut montrer Redis, alors que votre pool FPM ne le charge pas. Le symptôme côté appli : Class 'Redis' not found ou fallback silencieux sur un autre backend.

Astuce “prod-friendly” : dès que l’extension est active, vérifiez aussi la version (utile pour expliquer un comportement) :

php --ri redis | sed -n '1,40p'

Choisir les “bases” Redis : DB index, préfixes, ou instances dédiées (et le piège Cluster)

Redis propose des “bases” logiques numérotées (0..N-1) activées par databases dans redis.conf. Côté client phpredis, vous faites :

$redis = new Redis();
$redis->connect('127.0.0.1', 6379, 0.2);
$redis->auth('secret');
$redis->select(2); // DB 2
$redis->set('ps:cache:foo', 'bar', ['ex' => 60]);

Techniquement, ça marche. Opérationnellement, ça a deux limites majeures :

• Isolation faible : DB≠namespace sécurisé. Un FLUSHDB détruit tout le DB index, un KEYS * scanne l’espace, et les ACL n’isolent pas “par DB” de façon fine (vous contrôlez des commandes, pas un vrai multi-tenant).
• Redis Cluster : Redis Cluster ne gère pas les DB multiples comme Redis en mode standalone (en pratique, vous êtes sur la DB 0). La doc Redis le précise dans la partie Cluster : https://redis.io/docs/latest/operate/oss-and-stack/management/scaling/

Donc, si vous visez un Redis managé en mode cluster (ou un futur scale-out), investir aujourd’hui dans SELECT pour séparer les usages est un pari perdant. La stratégie la plus portable est : DB 0 + préfixes de clés (et éventuellement plusieurs instances / plusieurs ports). Exemple concret d’arborescence de clés :

• ps9:shop1:cache:* (cache applicatif)
• ps9:shop1:sessions:* (sessions)
• ps9:shop1:locks:* (verrous stock/checkout)

Quand préférer plusieurs instances plutôt qu’un simple préfixe ?

• Sessions : si Redis tombe ou évince, vous perdez des connexions. Une instance dédiée (sans éviction, mémoire réservée) réduit les effets de bord.
• Cache applicatif : peut tolérer allkeys-lfu / allkeys-lru.
• Verrous : exigent une latence stable ; éviter de les mettre sur une instance “bruyante” (gros volumes de cache, grosses valeurs sérialisées).

Mini-scénario typique (très courant en e-commerce) : une boutique PrestaShop multi-boutiques sur une VM (ex. OVHcloud Public Cloud) avec 60 workers PHP-FPM. Si vous activez pconnect() et que chaque worker maintient une connexion Redis, vous pouvez vous retrouver avec ≈ 60 connexions rien que pour le front, plus le backoffice, plus les crons. Sur une instance Redis partagée (cache + sessions + verrous), un incident de mémoire peut se traduire par une perte de sessions et une dégradation du checkout. La séparation par instance limite ce couplage.

Pour PrestaShop, cette séparation n’est pas un “détail”. Le core mélange déjà plusieurs formes de cache (Smarty, Symfony cache, cache de données), et vos modules ajoutent souvent des verrous ou des états temporaires. Si vous utilisez Redis pour de la concurrence sur stock (verrous), cloisonnez au minimum par préfixe, et évitez de cohabiter avec des données “non volatiles” dans le même espace mémoire sans politique d’éviction claire (voir Performance e-commerce : prévenir la concurrence sur les stocks avec Redis).

Paramétrage Redis côté serveur et options client PHP : ce qui impacte vraiment la prod

Le réglage déterminant côté Redis, c’est la mémoire : maxmemory + politique d’éviction. Sans cela, vous vous exposez à des OOM (killer) ou à des latences anormales (swap, fragmentation), surtout si Redis cohabite avec MySQL sur la même VM.

Pour un usage “cache pur”, une base saine ressemble à :

maxmemory 2gb
maxmemory-policy allkeys-lfu   # ou allkeys-lru selon votre profil
activedefrag yes               # réduit la fragmentation sur charges longues

Mais attention aux usages “mixtes” :

• Cache : allkeys-lru / allkeys-lfu se justifient.
• Sessions / verrous : vous voulez plutôt éviter l’éviction (ou isoler dans une instance dédiée). Dans ce cas, maxmemory-policy noeviction est cohérent… à condition de dimensionner la mémoire et de monitorer, sinon vous transformez un souci d’éviction en erreurs d’écriture.

Ensuite, la durabilité. Si vous utilisez Redis uniquement pour cache/sessions/verrous, désactivez les options de persistance qui ne vous servent pas, sinon vous ajoutez de l’I/O et des pauses (fork pour RDB, fsync pour AOF). Si en revanche Redis porte un état métier (mauvaise idée sur PrestaShop “standard”, mais ça arrive), vous devez traiter Redis comme une base : sauvegardes, réplication, plan de reprise. Ne confondez pas “ça redémarre vite” et “c’est durable”.

Côté sécurité (souvent négligée) : sur une boutique, Redis doit idéalement être local seulement (socket Unix ou bind privé), protégé par ACL/mot de passe, et jamais exposé à Internet. Une configuration “prudente” côté réseau est presque toujours plus rentable qu’un durcissement tardif après incident.

Côté PHP, trois paramètres font la différence :

1) Time-outs : connectTimeout court (ex. 100–300 ms) et readTimeout adapté (souvent 1–2 s). En cas de Redis dégradé, vous voulez échouer vite et fallback (sinon vous bloquez des workers FPM et vous amplifiez l’incident).
2) Connexions persistantes : pconnect() réduit l’overhead, mais chaque worker FPM peut ouvrir sa propre connexion persistante. Avec 30–80 workers, vous pouvez exploser maxclients.
3) Sérialisation : activez igbinary si disponible (réduit la taille des payloads et le CPU). Dans phpredis, c’est OPT_SERIALIZER.

$redis = new Redis();
$redis->pconnect('/var/run/redis/redis.sock', 0, 0.2);
$redis->setOption(Redis::OPT_PREFIX, 'ps9:shop1:');
$redis->setOption(Redis::OPT_SERIALIZER, Redis::SERIALIZER_IGBINARY);
$redis->setOption(Redis::OPT_READ_TIMEOUT, 1.0);

Deux détails pratiques en prod :

• Socket Unix vs TCP : sur la même machine, le socket Unix (/var/run/redis/redis.sock) réduit souvent la surface réseau et simplifie le “bind”, mais impose de gérer les droits (www-data / groupe). En conteneurs, TCP est souvent plus simple.
• Taille des valeurs : un cache Redis rempli de gros objets PHP sérialisés peut exploser la mémoire plus vite que prévu. Pour objectiver, échantillonnez avec MEMORY USAGE key (sur quelques clés représentatives) et comparez avec votre TTL.

Surveiller l’usage Redis (mémoire, hit ratio, évictions, latence) : commandes et métriques utiles

Si vous ne mesurez pas, vous ne savez pas si Redis améliore quoi que ce soit (ou s’il déplace juste la charge). En “debug terrain”, commencez par des commandes Redis natives :

redis-cli INFO memory
redis-cli INFO stats
redis-cli INFO clients
redis-cli LATENCY LATEST
redis-cli SLOWLOG GET 20
redis-cli MEMORY DOCTOR

Ce que vous cherchez : used_memory, used_memory_rss, mem_fragmentation_ratio, evicted_keys, keyspace_hits/keyspace_misses, instantaneous_ops_per_sec, blocked_clients.

Pour éviter l’interprétation “au feeling”, calculez un indicateur simple :

• Hit ratio = keyspace_hits / (keyspace_hits + keyspace_misses)
• proche de 0 : votre cache sert peu (mauvaises clés, TTL trop courts, ou cache contourné)
• qui monte dans le temps : Redis amortit réellement des calculs/requêtes

Trois signaux d’alerte fréquents (et actionnables) :

• evicted_keys augmente : la mémoire est trop basse ou la politique d’éviction n’est pas alignée avec vos usages (ex. sessions mélangées avec un cache très volumineux).
• mem_fragmentation_ratio durablement élevé : possible fragmentation ; activedefrag yes aide, mais vérifiez aussi les grosses valeurs et la pression mémoire globale (VM bruyante, swap).
• connected_clients grimpe : typiquement pconnect() + beaucoup de workers FPM + absence de plafonds (et parfois un pool FPM surdimensionné).

Pour une surveillance continue, ne réinventez pas la roue : exposez Redis via un exporter Prometheus (le plus courant : https://github.com/oliver006/redis_exporter), puis visualisez dans Grafana. Vous avez déjà la brique de déploiement côté Kubernetes/Helm dans Prometheus sur Kubernetes OVHcloud : déployer kube-prometheus-stack avec Helm et l’initialisation Grafana côté VM dans Grafana sur Ubuntu : installation APT et configuration initiale.

Exemples d’alertes “qui servent” (à adapter, pas à copier-coller aveuglément) :

• evicted_keys > 0 sur 5 min : vous perdez des clés faute de mémoire (ça peut casser sessions ou verrous).
• connected_clients proche de maxclients : vous êtes en train d’étrangler Redis (souvent lié à FPM + pconnect).
• latence > 5–10 ms p95 sur Redis local : CPU saturé, fork RDB, AOF fsync, ou VM bruyante.

Si vous êtes sur une infra non-K8s / plus “boîte à outils”, Netdata donne une visibilité immédiate sur Redis (CPU, mémoire, connexions, ops/s) sans pipeline complet Prometheus : Netdata monitoring : surveiller AWS, Kubernetes, bases de données et serveurs web. Et pour éviter le syndrome “alerte inutile”, structurez vos seuils comme dans Surveillance PrestaShop : tableau de bord, seuils et réduction des fausses alertes.

Enfin, gardez une métrique “business” dans le radar : si Redis sert le cache, vous devriez voir moins de charge MySQL (QPS, temps CPU, locks) et/ou un TTFB plus stable sous charge. Sinon, Redis peut être correctement “en place”… mais inutile.

Intégration concrète avec PrestaShop : sessions, cache applicatif, verrous (et limites du core)

Soyons clairs : le core PrestaShop ne fournit pas une configuration Redis “first-class” dans le backoffice (contrairement à Memcached). Donc, “Redis PHP” dans un contexte PrestaShop passe généralement par trois axes :

1) Sessions PHP dans Redis (gain direct sur MySQL, surtout si vos sessions sont lourdes).
2) Cache applicatif dans Redis (dans vos modules ou vos surcharges, via Symfony Cache ou via phpredis direct).
3) Verrous / anti-concurrence (checkout, stock, jobs).

Pour les sessions, le chemin le plus pragmatique est la config PHP, par pool FPM (ou php.ini) :

session.save_handler = redis
session.save_path = "unix:///var/run/redis/redis.sock?database=0&prefix=ps9:shop1:sess:&timeout=1&read_timeout=1"

Note : database= ici réintroduit la notion de DB index. Si vous visez un futur Redis Cluster, préférez DB 0 et jouez sur prefix=. Et n’oubliez pas que la perte de Redis = perte de sessions : prévoyez le comportement (reconnexion, réauth) et un timeout raisonnable.

Deux compléments importants pour des sessions robustes :

• Verrouillage de session : selon les paramètres disponibles côté handler Redis de PHP, activer le locking évite des corruptions/écrasements quand plusieurs requêtes concurrentes touchent la même session (fréquent avec AJAX + checkout). Si vous observez des comportements “fantômes” (panier qui revient en arrière, état incohérent), c’est une piste à creuser.
• TTL et volumétrie : si vos sessions expirent après 30 minutes d’inactivité mais que vous stockez beaucoup de données, votre Redis peut grossir vite. Mesurez le nombre de clés sess:* et la mémoire associée (sur un échantillon) pour dimensionner maxmemory.

Pour le cache applicatif “propre” côté Symfony (modules PrestaShop 8/9), vous pouvez vous appuyer sur symfony/cache et son RedisAdapter (doc Symfony : https://symfony.com/doc/current/components/cache.html). Même si tout PrestaShop n’est pas câblé Symfony “comme une app standard”, vos modules peuvent utiliser un pool dédié pour éviter de polluer le cache global. Référence utile sur la structure des services côté modules : Module PrestaShop 9 : structure, services et bonnes pratiques Symfony.

Sur les verrous, soyez intentionnel : un verrou Redis doit être court, avec un TTL, et doit survivre à une latence raisonnable. Si vous voyez des “blocages” (commandes qui restent en “pending”, stock qui ne se décrémente pas), vérifiez à la fois l’implémentation applicative et la santé Redis (blocked_clients, SLOWLOG, latence).

Checklist opérationnelle : activer, séparer, valider sous charge

Avant d’activer Redis en prod, faites une passe “risque” : redémarrer PHP-FPM coupe des requêtes en vol si vous n’avez pas de reload maîtrisé ; un mauvais maxmemory-policy peut supprimer des clés critiques ; un pconnect() mal dimensionné peut vous faire atteindre maxclients. Et si vous êtes en période de pics (soldes, campagnes), planifiez ça comme un changement infra (cf. PrestaShop pics de trafic : architecture cloud scalable et haute disponibilité).

Checklist courte (et réellement utile) avant bascule :

• [ ] Extension chargée dans FPM et CLI (php --ri redis + validation via HTTP)
• [ ] Redis non exposé publiquement (bind privé / socket Unix, pare-feu)
• [ ] maxmemory défini + politique d’éviction alignée avec l’usage
• [ ] Préfixe de clés standardisé (inclure environnement + shop)
• [ ] Stratégie de séparation décidée (au minimum préfixes ; idéalement instance dédiée pour sessions si critique)
• [ ] Timeouts PHP fixés (connexion courte, lecture raisonnable)
• [ ] Limites de connexions anticipées (pconnect + nombre de workers)
• [ ] Runbook prêt (commandes redis-cli, rollback, qui appeler)

Validez ensuite avec métriques, pas au feeling. Sur un environnement de staging réaliste, lancez un test de charge et mesurez : TTFB, erreurs 5xx, saturation FPM, instantaneous_ops_per_sec, latence Redis, hit ratio, évictions. Votre méthode doit être reproductible (voir Audit performance PrestaShop : méthode en 6 étapes reproductibles et PrestaShop performance : monitoring, tests de charge et runbooks soldes).

Un test “simple mais révélateur” : faites deux runs de charge identiques (même dataset, même trafic), d’abord Redis désactivé, puis Redis activé, et comparez :

• temps moyens + p95/p99 (pas seulement la moyenne),
• taux d’erreurs,
• CPU FPM et temps passé en “idle vs busy”,
• côté Redis : latence, ops/s, hit ratio,
• côté MySQL : QPS et temps CPU.

Enfin, documentez un runbook simple : commandes redis-cli à lancer, seuils d’alerte, procédure de rollback (désactiver extension / repasser sessions en fichiers / couper un module), et règles de sécurité (bind local, socket Unix, ACL, pas d’accès Internet). Redis est extrêmement tolérant tant que vous l’utilisez comme cache. Dès que vous le laissez devenir un SPOF applicatif, il faut le traiter comme une vraie brique de production, au même titre que MySQL ou votre reverse proxy (voir aussi Cache PrestaShop : Varnish, Redis, Memcached et OPcache côté serveur pour situer Redis dans l’architecture globale).