Redis PrestaShop : configurer le cache sur VPS ou serveur dédié

Table des matières :

1. Redis dans une boutique PrestaShop : ce que vous allez vraiment accélérer (et ce que vous ne devez pas promettre)
2. Installer Redis sur VPS / serveur dédié : paquet, service systemd et prérequis noyau
3. Redis comme cache : configuration mémoire, persistence, eviction (et pourquoi c’est là que tout se joue)
4. Durcir Redis sur serveur : loopback, unix socket, ACL, et séparation des bases
5. Côté PHP-FPM : extension phpredis, sessions Redis et pièges de connexion
6. Brancher Redis à PrestaShop : stratégies réalistes (sessions, cache Symfony, cache applicatif via module)
7. Validation en production : tests, indicateurs Redis, et supervision exploitable (pas “j’ai mis Redis donc ça va mieux”)

Redis dans une boutique PrestaShop : ce que vous allez vraiment accélérer (et ce que vous ne devez pas promettre)

Sur PrestaShop 8.x et 9.x (PHP 8.1–8.5 côté cœur, avec des stacks prod en 8.2/8.3 très fréquentes), Redis n’est pas un « cache magique » qui remplace tout. Il apporte surtout un stockage RAM partagé et rapide pour des données éphémères : sessions, verrous (locks), petits objets sérialisés, résultats de calculs coûteux, fragments de configuration. En revanche, il ne compensera jamais un MySQL mal indexé, une surcharge PHP-FPM, ni un front non caché côté HTTP.

Pour cadrer les attentes (et éviter les promesses intenables), voici ce que Redis accélère le plus souvent dans une boutique PrestaShop, et ce qui relève d’autres couches :

Besoin	Redis aide ?	Pourquoi	Ce qui aide davantage si ça ne suffit pas
Sessions (Front/BO)	Oui	Évite I/O disque et contention sur fichiers sess_*	Dimensionner PHP-FPM, affiner pm.*, stockage local rapide
Locks / concurrence (stock, panier, tâches)	Oui	Verrouillage rapide, faible latence	Repenser les sections critiques + transactions DB
Cache « applicatif » ciblé (résultat d’un calcul, mapping, API)	Oui	Stockage en RAM, TTL, évictions contrôlées	Symfony Cache, invalidation, TTL cohérents
Cache BO / services Symfony	Oui	Composant Cache natif	Mécanismes Symfony + tuning OPcache
Cache des pages publiques (visiteurs non loggés)	Pas l’outil principal	Il manque la couche HTTP, variation, purge	Varnish / Nginx microcache / CDN
Requêtes SQL lentes	Non (directement)	Redis ne corrige pas un plan SQL	Index, slow log, requêtes, schéma
PHP trop lent (CPU)	Indirectement	Moins de calculs répétés	Profiling, OPcache, refacto modules

Le point qui surprend souvent : le cœur de PrestaShop ne fournit pas un backend Redis “first-class” universel pour son mécanisme historique Cache (les drivers disponibles varient selon versions et extensions, mais Redis n’est pas une cible standard). Si vous voulez un cache applicatif Redis propre, vous passez soit par un module qui l’implémente, soit par Symfony Cache (côté BO et services), soit par des usages ciblés (sessions, locks, file de messages). Pour une vue d’ensemble des couches possibles (OPcache, Varnish, Redis/Memcached), gardez sous la main : Cache PrestaShop : Varnish, Redis, Memcached et OPcache côté serveur et, pour le multi-niveaux en période de charge, PrestaShop soldes : optimiser le cache multi-niveaux et CCC.

Enfin, Redis doit être vu comme une ressource système à dimensionner et à surveiller (RAM, eviction, latence). Les gains sont concrets quand vous réduisez la pression sur MySQL et/ou sur le disque (sessions sur FS, locks en base, etc.). Si vous cherchez des métriques et une méthode reproductible, vous aurez plus de résultats en l’intégrant à une démarche de mesure : Audit performance PrestaShop : méthode en 6 étapes reproductibles et Performance PrestaShop : benchmarks et optimisation PHP-FPM, OPCache, MySQL.

Note “terrain” (VPS/dédié en France/UE) : Redis apporte surtout sa valeur quand il reste sur la même machine (ou au minimum dans le même datacenter) que PHP-FPM. Mettre Redis « au loin » (autre région/cloud) peut ajouter une latence réseau qui annule une partie des gains, surtout sur des appels très fréquents (sessions, locks).

Installer Redis sur VPS / serveur dédié : paquet, service systemd et prérequis noyau

Les exemples ci-dessous ciblent Ubuntu Server 22.04/24.04 ou Debian 12, avec Redis 7.x (versions exactes dépendantes des dépôts). Sur un VPS/dédié, évitez les installations « compilées à la main » si vous n’avez pas un processus de patching clair : la sécurité et les correctifs importent plus que le micro-gain de perf.

Installation basique :

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

Si PONG répond, vous avez un service fonctionnel. Le reste consiste à le rendre prévisible sous charge (backlog, overcommit, THP). Redis est très sensible à certains paramètres du noyau Linux. Minimum syndical sur un serveur dédié/VM (à adapter à votre politique) :

# Connexions en rafale
printf "net.core.somaxconn = 65535\n" | sudo tee /etc/sysctl.d/99-redis.conf
# Overcommit mémoire conseillé par Redis
printf "vm.overcommit_memory = 1\n" | sudo tee -a /etc/sysctl.d/99-redis.conf
sudo sysctl --system

Deux compléments utiles sur des serveurs e-commerce (sans tomber dans l’optimisation “au hasard”) :

• Fichiers ouverts : un Redis + PHP-FPM + MySQL peuvent vite monter. Vérifiez les limites systemd/ulimit (selon votre distro et vos unités).
• Backlog TCP : si vous gardez Redis en TCP (même local), somaxconn limite la file d’attente. Un somaxconn trop bas peut provoquer des refus lors de micro-pics (ex. purge, crawlers, synchro ERP).

Transparent Huge Pages (THP) peut créer des latences (pics intermittents) lors de la gestion mémoire. En prod, l’approche “propre” est de le désactiver via systemd, de façon persistante. Exemple (override systemd) :

sudo systemctl edit redis-server

Puis :

[Service]
ExecStartPre=/bin/sh -c 'echo never > /sys/kernel/mm/transparent_hugepage/enabled'
ExecStartPre=/bin/sh -c 'echo never > /sys/kernel/mm/transparent_hugepage/defrag'

Ensuite :

sudo systemctl daemon-reload
sudo systemctl restart redis-server

Checklist rapide post-install (utile en runbook) :

# Redis actif
systemctl status redis-server --no-pager

# Paramètres noyau en place
sysctl net.core.somaxconn vm.overcommit_memory

# THP (doit afficher "never" entre crochets)
cat /sys/kernel/mm/transparent_hugepage/enabled

Redis comme cache : configuration mémoire, persistence, eviction (et pourquoi c’est là que tout se joue)

Si votre objectif est uniquement le cache, la persistance RDB/AOF est généralement un coût inutile : plus d’I/O disque, plus de CPU, et des pauses possibles lors de snapshots. En environnement e-commerce, perdre un cache n’est pas grave ; perdre du temps CPU/disk pendant un pic de trafic l’est. Sur un Redis dédié au cache, on coupe souvent la persistance :

# /etc/redis/redis.conf (extraits)
save ""
appendonly no

Le dimensionnement mémoire doit être explicite. Sans maxmemory, Redis peut consommer jusqu’à épuiser la RAM et déclencher l’OOM killer (vous perdrez alors… PHP-FPM ou MySQL, selon le hasard). Une règle pragmatique sur VPS multi-services : 10–25% de la RAM pour Redis cache si vous avez déjà OPcache et une base locale ; plus si Redis sert aussi aux sessions et locks.

Repère simple (à ajuster après observation) :

RAM serveur	Redis “cache pur” (ordre de grandeur)	Redis cache + sessions/locks
4 Go	256–512 Mo	512 Mo–1 Go
8 Go	512 Mo–1 Go	1–2 Go
16 Go	1–2 Go	2–4 Go

Exemple :

maxmemory 1024mb
maxmemory-policy allkeys-lfu

Pourquoi allkeys-* ? Parce que vous voulez que Redis puisse évincer n’importe quelle clé plutôt que de tomber en erreur (noeviction) au moment le plus critique. LFU (Least Frequently Used) est souvent plus stable qu’un LRU naïf quand vous avez des « hot keys » (pages / configs très consultées) et une longue traîne. À tester selon votre dataset : l’important n’est pas la théorie, c’est le ratio keyspace_hits/keyspace_misses et le taux d’evicted_keys.

Deux pièges fréquents en boutique :

• “Je mets maxmemory trop haut” : Redis n’est pas seul. Entre MySQL (buffer pool), PHP-FPM (workers), OPcache, et le FS cache, vous avez besoin d’air. Un Redis trop gourmand finit par dégrader le reste.
• Fragmentation RSS : vous pouvez avoir used_memory “raisonnable” mais un used_memory_rss plus élevé. En environnement long-vivant, activez éventuellement la défragmentation active (à tester, car elle consomme CPU) :

activedefrag yes

Enfin, côté sécurité/positionnement : Redis est conçu pour être consommé par des clients de confiance dans un environnement maîtrisé. Concrètement : pas d’exposition Internet, pas de 6379 ouvert “pour tester”. La doc officielle Redis sur la sécurité est une référence utile : https://redis.io/docs/latest/operate/oss-and-stack/management/security/

Durcir Redis sur serveur : loopback, unix socket, ACL, et séparation des bases

Le schéma le plus robuste sur VPS/dédié monolithique : Redis uniquement local (127.0.0.1) ou via socket Unix, avec permissions restreintes. Le socket Unix est un bon compromis : moins d’overhead TCP et surface réseau quasi nulle (et, en pratique, cela évite aussi certaines erreurs de firewall/route).

Exemple de config (extraits) :

bind 127.0.0.1 ::1
protected-mode yes
port 6379

# Option socket (alternative au port)
unixsocket /run/redis/redis.sock
unixsocketperm 660

Ensuite, vous gérez les droits : ajoutez l’utilisateur du pool PHP-FPM (souvent www-data) au groupe redis, ou l’inverse selon votre politique. Si vous conservez un port TCP, mettez au minimum un filtrage local (ufw/nftables) et n’ouvrez pas 6379 vers l’extérieur.

Pour l’authentification, évitez l’ancien requirepass si vous êtes en Redis récent : utilisez ACL (Redis 6+). Vous pouvez créer un utilisateur « cache » sans commandes dangereuses (pas de CONFIG, pas de FLUSHALL, etc.). Exemples (à adapter) :

user prestashop on >UN_MOT_DE_PASSE_FORT ~ps:* +@read +@write -flushall -flushdb -config

Bonnes pratiques réalistes (qui évitent les mauvaises surprises) :

• Préfixer toutes les clés (ps:*, pssess:*, locks:*) : cela évite les collisions si vous mutualisez, et cela simplifie la purge ciblée.
• Ne pas utiliser KEYS en prod : c’est bloquant sur de gros keyspaces. Préférez SCAN en diagnostic.
• Éviter de mélanger “sessions” et “cache volatil” si vous utilisez une politique d’éviction agressive : une eviction de session, c’est un logout/une perte de panier. Dans une infra exigeante, on sépare souvent :
• soit en instances Redis distinctes (plus propre),
• soit au minimum avec des DB/prefix + politiques/alertes adaptées.

Enfin, utilisez des DB ou des préfixes de clés pour isoler les usages : DB 1 pour sessions, DB 2 pour cache applicatif, DB 3 pour locks, etc. Ce n’est pas une isolation de sécurité (c’est la même instance), mais ça simplifie les purges, les métriques et les diagnostics. Pour la partie PHP/extension et bonnes pratiques de bases/monitoring, le complément utile est : Redis PHP : activer l’extension, choisir les bases et surveiller l’usage.

Côté PHP-FPM : extension phpredis, sessions Redis et pièges de connexion

Sur Debian/Ubuntu, l’extension « phpredis » est normalement packagée (php-redis). Vérifiez la version de PHP en CLI et FPM (elles divergent parfois si vous avez plusieurs SAPI). Exemple (PHP 8.3) :

sudo apt install php8.3-redis
php -m | grep -i redis
php --ri redis
sudo systemctl reload php8.3-fpm

Le piège classique en prod : multiplier les connexions Redis au point de saturer maxclients ou de créer une latence serveur. Avec PHP-FPM, chaque worker peut ouvrir une connexion. Si vous avez 80 workers et 3 pools, vous explosez vite.

Repère de calcul (simplifié, mais utile pour dimensionner) :

• Connexions Redis ≈ workers × (connexions par requête si non persistantes)
• En persistant, vous tendez plutôt vers workers connexions “stables” (plus d’un si vous segmentez par DB/usage)

Donc, si vous avez par exemple 2 pools (front + BO) à 50 workers chacun, viser 100–150 maxclients peut être trop juste une fois que vous ajoutez cron, workers, outils de supervision, et quelques connexions admin. L’idée n’est pas de mettre un chiffre énorme “au cas où”, mais d’éviter le goulot d’étranglement invisible.

Pour les sessions, l’impact est souvent immédiat : vous supprimez des lectures/écritures de fichiers sess_* sur disque (particulièrement pénalisantes sur stockage réseau, ou quand tmpfs n’est pas en place). Configuration type (dans php.ini ou mieux : dans le pool FPM dédié au vhost via php_admin_value) :

session.save_handler = redis
; TCP
session.save_path = "tcp://127.0.0.1:6379?database=1&prefix=pssess:&timeout=2.5&read_timeout=2.5&persistent=1"
; ou socket unix
; session.save_path = "unix:///run/redis/redis.sock?database=1&prefix=pssess:&timeout=2.5&read_timeout=2.5&persistent=1"

Trois points de vigilance souvent oubliés :

• Timeouts réalistes : trop bas = erreurs intermittentes ; trop haut = workers PHP bloqués quand Redis a un souci. Sur Redis local, 1–3 secondes est souvent un bon ordre de grandeur.
• GC des sessions : Redis stocke les sessions avec un TTL. Assurez-vous que session.gc_maxlifetime est cohérent avec votre logique métier (panier, checkout), sinon vous “perdez” des sessions plus vite que prévu.
• Taille des sessions : certains modules chargent beaucoup d’infos en session (étapes checkout, transporteurs, règles panier). Surveillez l’évolution de used_memory après migration.

Validez ensuite avec un test simple : ouvrir une session, puis vérifier sur Redis (préférez SCAN à KEYS si vous avez déjà beaucoup de clés) :

redis-cli -n 1 scan 0 match 'pssess:*' count 20

Sur des boutiques à trafic soutenu, ce changement seul peut réduire des effets de contention FS et lisser le TTFB, à condition que Redis soit local et correctement dimensionné.

Brancher Redis à PrestaShop : stratégies réalistes (sessions, cache Symfony, cache applicatif via module)

Première stratégie (safe et rentable) : sessions Redis, décrite au-dessus. Elle est quasiment indépendante de PrestaShop, donc peu fragile lors des mises à jour. Attention toutefois : certains modules manipulent des sessions volumineuses (panier/checkout), et la sérialisation PHP peut gonfler ; surveillez used_memory et la taille moyenne des valeurs. Si vous observez des backoffice lents, commencez par vérifier vos requêtes MySQL et la latence DB : Requêtes MySQL lentes PrestaShop : activer slow query log.

Deuxième stratégie (moderne, mais à cadrer) : utiliser Symfony Cache avec un pool Redis pour les services BO / vos modules. Symfony supporte Redis via ses adaptateurs PSR-6/PSR-16, ce qui permet un cache “propre” et testable, sans couplage au cœur PrestaShop. En pratique, sur PrestaShop 9 (Symfony 6.4), créez un pool dédié à votre module plutôt que d’essayer de remplacer cache.app global (risqué, et pas toujours utile).

Exemple minimal dans un module (fichier modules/votre_module/config/services.yml) :

services:
  votre_module.redis_connection:
    class: Redis
    factory: ['Symfony\\Component\\Cache\\Adapter\\RedisAdapter', 'createConnection']
    arguments:
      - 'redis://127.0.0.1:6379/2'

  votre_module.cache_pool:
    class: Symfony\\Component\\Cache\\Adapter\\RedisAdapter
    arguments:
      - '@votre_module.redis_connection'
      - 'ps:vm:'
      - 3600

Mini-scenario concret (typique e-commerce) : vous appelez une API transporteur ou ERP pour calculer un délai/stock “réel” et vous refaites l’appel à chaque affichage produit. Mettre en cache le résultat normalisé (par produit + pays + groupe client, TTL 5–30 min selon la fraîcheur attendue) peut :

• réduire la facture API,
• réduire la latence côté front,
• limiter la charge PHP lors d’un pic (soldes, campagnes).

Puis, dans votre code, utilisez PSR-6 (getItem()/save()) pour cache de résultats coûteux (ex. agrégats de prix, mapping ERP, rendu de blocs). Évitez de cacher des objets PrestaShop bruts (Product, Cart) sérialisés sans contrôle : vous vous exposez à des invalidations incohérentes (changement de prix, stock, règles panier). À ce stade, c’est aussi le bon moment pour traiter les problèmes de concurrence (ex. stock/panier) avec des locks Redis plutôt qu’un bricolage SQL : Performance e-commerce : prévenir la concurrence sur les stocks avec Redis.

Troisième stratégie (souvent mal comprise) : « mettre PrestaShop en full cache Redis ». Le cœur ne vous donne pas une bascule propre. Si votre besoin est du cache HTTP (pages catégories/produits pour visiteurs non loggés), Redis n’est pas l’outil principal : vous voulez Varnish/Nginx microcache, éventuellement avec ESI. Pour cadrer correctement cette couche (et éviter de “cacher” des pages personnalisées), voyez : PrestaShop Docker : configurer Varnish VCL et valider le cache X-Cache et Varnish Cache : configuration ESI pour optimiser le cache par fragments.

Validation en production : tests, indicateurs Redis, et supervision exploitable (pas “j’ai mis Redis donc ça va mieux”)

Avant/après : mesurez. Sur PrestaShop, vous cherchez typiquement une baisse du TTFB et un lissage des latences sur les endpoints critiques (catégorie, produit, recherche interne, panier, checkout). Faites un test de charge reproductible, ou au minimum des séries curl -w en warm/cold cache, puis corrélez avec PHP-FPM (pm.status_path) et MySQL. Pour le cadrage TTFB, référez-vous à : TTFB PrestaShop : réduire le Time To First Byte sous 200 ms.

Méthode simple (très opérationnelle) pour valider que Redis aide vraiment :

1. Mesurez 30–50 requêtes sur une page cible (produit/catégorie) sans trafic parasite.
2. Activez sessions Redis (ou votre pool cache module).
3. Refaites exactement la même série (mêmes URLs, mêmes headers, même IP si possible).
4. Comparez :

• médiane et p95 du TTFB,
• CPU PHP-FPM,
• I/O disque (si vous aviez des sessions fichiers),
• métriques Redis (hits/misses, latence).

Côté Redis, les commandes utiles (à automatiser en runbook) :

redis-cli info memory
redis-cli info stats
redis-cli --latency-history -i 1
redis-cli slowlog get 20

Indicateurs à suivre : used_memory, used_memory_rss, mem_fragmentation_ratio (attention au RSS qui dérive), evicted_keys (si ça monte, votre maxmemory est trop bas ou votre dataset trop gros), keyspace_hits/misses (efficacité réelle), et la latence (p95/p99 si vous exportez vers Prometheus).

Interprétations rapides (pratiques en incident) :

• evicted_keys augmente pendant les pics : votre stratégie d’éviction fonctionne, mais vous manquez de mémoire ou vous mettez en cache trop large (TTL trop long, clés trop nombreuses).
• keyspace_misses explose : vous cachez mal (mauvais TTL, clés trop variables, faible réutilisation). Redis devient un coût, pas un gain.
• Latence qui “sawtooth” ou pics récurrents : suspecter THP, pression mémoire, swap, ou CPU saturé (Redis est mono-thread pour l’exécution des commandes, même s’il a des threads I/O).

Pour la supervision, vous pouvez passer par un exporter Prometheus (redis_exporter) et construire des dashboards Grafana. Si vous êtes déjà outillés Prometheus/Grafana, alignez vos métriques Redis avec le reste de la stack (HAProxy, PHP-FPM, MySQL). Les articles connexes pour une supervision cohérente : Surveillance PrestaShop : tableau de bord, seuils et réduction des fausses alertes et Grafana sur Ubuntu : installation APT et configuration initiale.

Enfin, traitez Redis comme une dépendance critique : redémarrage contrôlé (maintenance window), politique de mise à jour, et plan de dégradation. Si Redis tombe et que vos sessions en dépendent, vous déconnectez tout le monde (ce qui peut être acceptable, mais doit être connu). Dans les runbooks « soldes/pics de trafic », documentez le comportement attendu (sessions perdues, cache froid), et combinez avec des pratiques infra (rate limiting, TLS termination, etc.) si vous êtes en frontal HAProxy : HAProxy reverse proxy : terminaison TLS, rate limiting et supervision Prometheus.