Un cache d'objets garde le RÉSULTAT du travail en mémoire pour que la requête suivante ne le refasse pas. Sur un site qui pose à la base les mêmes questions à chaque page, l'effet est énorme. Sur un site dont les pages sont lentes pour d'autres raisons, il est nul.

Quand il aide

  • Un CMS qui charge des dizaines de lignes de réglages à chaque requête - WordPress demande ses options sur chaque page sans exception.
  • Menus, taxonomies, métadonnées d'utilisateur : petits, répétés, identiques.
  • Les sessions, qui sinon deviennent des milliers de petits fichiers sur le disque.

Quand il n'aide pas

Une page lente à cause d'UNE requête sur une grande table reste exactement aussi lente. Le cache économise le travail répété, pas le travail coûteux. Corrigez d'abord la requête ; la mettre en cache ne fait que cacher sa gravité jusqu'à ce que le cache soit froid.

Fixez une limite de mémoire et une politique d'éviction

maxmemory 256mb
maxmemory-policy allkeys-lru

Sans maxmemory, Redis grossit jusqu'à ce que la machine n'ait plus de mémoire, et le noyau tue alors quelque chose - souvent la base. allkeys-lru jette plutôt la clé la moins récemment utilisée, ce qui est le rôle d'un cache.

Liez-le à localhost

Redis n'a pas d'authentification par défaut. Un Redis joignable depuis internet est une porte ouverte : on peut lui demander d'écrire des fichiers. Liez-le à 127.0.0.1 et exigez un mot de passe.
bind 127.0.0.1
requirepass a-long-random-string

Vérifiez qu'il sert vraiment

redis-cli info stats | grep -E "keyspace_hits|keyspace_misses"

Des succès bien au-dessus des échecs veut dire qu'il fonctionne. Des échecs dominants veut dire que les clés expirent trop vite ou que quelque chose vide le cache à chaque requête.

Un cache de pages et un cache d'objets sont deux choses différentes. Le cache de pages sert une page entière déjà faite et aide les visiteurs anonymes ; le cache d'objets aide les visiteurs connectés, dont les pages ne peuvent pas être partagées.