Una caché de objetos guarda el RESULTADO del trabajo en memoria para que la siguiente petición no lo repita. En un sitio que le hace a la base las mismas preguntas en cada página, el efecto es enorme. En un sitio cuyas páginas van lentas por otros motivos, es nulo.

Cuándo ayuda

  • Un gestor que carga decenas de filas de ajustes en cada petición: WordPress pide sus opciones en absolutamente todas las páginas.
  • Menús, taxonomías, metadatos de usuario: pequeños, repetidos, idénticos.
  • Las sesiones, que si no acaban siendo miles de archivos diminutos en el disco.

Cuándo no ayuda

Una página lenta por UNA consulta sobre una tabla grande sigue exactamente igual de lenta. La caché ahorra trabajo repetido, no trabajo caro. Arregle primero la consulta; cachearla solo esconde lo mala que es hasta que la caché se enfría.

Ponga un límite de memoria y una política de expulsión

maxmemory 256mb
maxmemory-policy allkeys-lru

Sin maxmemory, Redis crece hasta que la máquina se queda sin memoria, y entonces el núcleo mata algo, a menudo la base de datos. allkeys-lru descarta en cambio la clave usada hace más tiempo, que es lo que debe hacer una caché.

Átelo a localhost

Redis no lleva autenticación por defecto. Un Redis alcanzable desde internet es una puerta abierta: se le puede ordenar escribir archivos. Átelo a 127.0.0.1 y exija contraseña.
bind 127.0.0.1
requirepass a-long-random-string

Compruebe que de verdad se está usando

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

Aciertos muy por encima de fallos quiere decir que funciona. Que dominen los fallos quiere decir que las claves caducan demasiado rápido o que algo vacía la caché en cada petición.

Una caché de páginas y una caché de objetos son cosas distintas. La de páginas sirve una página entera ya terminada y ayuda al visitante anónimo; la de objetos ayuda al que tiene sesión iniciada, cuyas páginas no se pueden compartir.