Configurar Redis como caché de objetos para WordPress

Qué hace una caché de objetos Redis para WordPress

Una caché de objetos Redis para WordPress almacena en memoria los resultados de las consultas a la base de datos, de modo que la siguiente petición los lee desde Redis en lugar de volver a consultar MySQL. WordPress ya incluye una caché de objetos en el núcleo, WP_Object_Cache, pero se almacena en la memoria de PHP y se descarta cuando termina la petición. Un archivo drop-in la reemplaza por otra que se comunica con Redis, de modo que la caché persiste de una petición a la siguiente.

La caché de objetos no es una caché de páginas, y esta diferencia determina si esta guía le resultará útil. Una caché de páginas almacena el HTML final de una URL y lo sirve de nuevo sin ejecutar PHP. Es más rápida que cualquier operación que Redis pueda realizar y funciona para los visitantes que no han iniciado sesión. En cuanto alguien inicia sesión, añade un artículo al carrito o abre el área de administración, la caché de páginas deja de intervenir y WordPress ejecuta la petición completa: arranque, plugins y consultas. Una caché de objetos hace que esa petición sea menos costosa. Es la herramienta para el tráfico que una caché de páginas no puede atender: sesiones iniciadas, carritos, pago y wp-admin. En una tienda WooCommerce, ese es el grueso del tráfico costoso.

Ambas soluciones se complementan y, en un sitio con mucha carga, se necesitan las dos. Determine con claridad qué problema está solucionando. Un sitio informativo con lectores anónimos obtiene casi toda su velocidad de una caché de páginas, y añadir Redis cambia muy poco.

Antes de empezar, tenga en cuenta una limitación importante. Una caché de objetos no hace que una consulta lenta sea rápida. Elimina la repetición de una consulta que ya se ejecutó. La primera petición después de un fallo de caché tiene el coste completo, por lo que un plugin que ejecuta una consulta sin índice seguirá ejecutándola una vez durante cada periodo de vida de la caché.

Qué necesita primero

• Un VPS con Linux, acceso a un shell y sudo. No se necesita un panel de control.
• WordPress servido por PHP-FPM, por ejemplo, en una pila LAMP en Ubuntu 24.04.
• WP-CLI instalado en el servidor. Cada paso tiene un equivalente en la pantalla de administración, pero la versión mediante shell es más rápida.
• Redis en el mismo equipo que PHP. La latencia es el objetivo principal, y un salto de red lo anula.

Los comandos siguientes están escritos para Ubuntu 24.04 con PHP 8.3 y el usuario web www-data. Adapte la versión de PHP y el usuario a su servidor. Ejecute los comandos wp desde el directorio de WordPress, que contiene wp-config.php.

Instalar Redis y la extensión de PHP

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

redis-cli ping debería responder PONG. Si muestra Could not connect to Redis at 127.0.0.1:6379: Connection refused, el servidor no está en ejecución. Lea systemctl status redis-server antes de continuar.

php-redis es PhpRedis, la extensión en C de PECL. Es más rápida que Predis, que está escrita íntegramente en PHP, y el plugin la usa automáticamente cuando está disponible. PHP-FPM carga las extensiones al iniciar. Por tanto, la nueva extensión no estará disponible hasta que reinicie el pool.

sudo systemctl restart php8.3-fpm
php -m | grep redis

Tenga cuidado con esa última comprobación: php -m muestra los módulos del PHP de la línea de comandos, y FPM puede cargar un conjunto diferente. La comprobación válida es la de los diagnósticos del propio plugin, más adelante.

En agosto de 2026, Ubuntu 24.04 proporciona Redis 7.0.15, una versión adecuada para una caché de objetos. Si prefiere una versión actual, Redis publica su propio repositorio APT.

sudo apt install -y lsb-release curl gpg
curl -fsSL https://packages.redis.io/gpg | sudo gpg --dearmor -o /usr/share/keyrings/redis-archive-keyring.gpg
sudo chmod 644 /usr/share/keyrings/redis-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/redis-archive-keyring.gpg] https://packages.redis.io/deb $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/redis.list
sudo apt update
sudo apt install -y redis

Si su distribución proporciona Valkey, el fork iniciado tras el cambio de licencia de 2024, usa el mismo protocolo y todo lo indicado a continuación se aplica sin cambios.

Vincule Redis de modo que no pueda acceder nadie más

Redis no tiene una contraseña de forma predeterminada. Cualquier proceso que pueda abrir una conexión al puerto 6379 puede leer todos los valores almacenados en caché y ejecutar FLUSHALL. Las instancias expuestas a Internet aparecen en los escáneres en cuestión de horas, por lo que la configuración de red debe hacerse antes del ajuste de rendimiento.

Abra /etc/redis/redis.conf y confirme estas líneas:

bind 127.0.0.1 -::1
protected-mode yes

Después, compruebe qué está escuchando realmente, porque el archivo de configuración es una declaración y ss es la evidencia.

sudo ss -lntp | grep 6379

127.0.0.1:6379 es el resultado esperado. 0.0.0.0:6379 significa que Redis está respondiendo en la interfaz pública: corrija la línea bind y reinicie el servicio.

Cuando PHP y Redis se ejecutan en el mismo equipo, un socket Unix es mejor que TCP sobre loopback. No hay una pila TCP en el trayecto y el acceso se decide mediante permisos de archivo, en lugar de depender de una regla del firewall que podría cambiar más adelante.

unixsocket /run/redis/redis-server.sock
unixsocketperm 770

El socket pertenece al usuario y grupo redis, por lo que el usuario del servidor web debe añadirse a ese grupo.

sudo systemctl restart redis-server
sudo usermod -aG redis www-data
sudo systemctl restart php8.3-fpm
redis-cli -s /run/redis/redis-server.sock ping

Esto también debe mostrar PONG. Could not connect to Redis at /run/redis/redis-server.sock: Permission denied significa que el grupo no se ha aplicado. Compruebe id www-data y recuerde que un proceso PHP-FPM en ejecución conserva los grupos que tenía al iniciarse; por eso el reinicio aparece en la lista. Mantenga TCP habilitado hasta comprobar que el socket funciona; de lo contrario, un error tipográfico podría dejar ambos métodos inaccesibles a la vez.

¿Cuánta memoria debe tener Redis?

Calcule el valor a partir de su propio servidor. Redis sin maxmemory crece hasta que el kernel se queda sin memoria y el OOM killer termina un proceso, normalmente el más grande, que en un servidor WordPress suele ser MySQL. journalctl -k | grep -i "out of memory" muestra esa terminación después de que ocurre, y para entonces el sitio ya está caído.

Empiece con la RAM total y reste los consumos. MySQL o MariaDB reserva innodb_buffer_pool_size, además de los búferes por conexión. PHP-FPM consume pm.max_children multiplicado por el tamaño residente real de un worker, normalmente entre 64 MB y 128 MB en un sitio con muchos plugins. El kernel y el servidor web necesitan unos cientos de megabytes. Lo que queda es su límite máximo, y Redis recibe una parte.

Ahora mida en lugar de hacer estimaciones. Después de un día con tráfico real:

redis-cli info memory | grep -E 'used_memory_human|maxmemory_human|maxmemory_policy'
redis-cli dbsize

Si used_memory_human se mantiene muy por debajo de su límite, reduzca el límite y devuelva la RAM a MySQL, que la aprovechará mejor. Si alcanza el límite y evicted_keys aumenta durante todo el día, súbalo. Establezca el valor en /etc/redis/redis.conf.

maxmemory 256mb
maxmemory-policy allkeys-lru

redis-cli config set maxmemory 256mb se aplica de inmediato y se pierde en el siguiente reinicio, igual que con un sysctl -w sin más. Edite el archivo, ejecute sudo systemctl restart redis-server y vuelva a leer el valor. También conviene establecer un segundo límite: un límite MemoryMax en la unidad de systemd evita que un Redis mal configurado deje el servidor fuera de servicio. Establézcalo por encima de maxmemory, nunca con el mismo valor, porque un límite de cgroup termina el proceso en lugar de expulsar una clave. Si Redis se ejecuta en un contenedor junto a WordPress, la misma cifra debe ir en los límites de memoria de su archivo Compose, y el mismo razonamiento determina la elección entre ejecutar la base de datos en Docker o en el host.

Elija deliberadamente la política de desalojo

Una instancia nueva de Redis usa noeviction de forma predeterminada. Compruebe la suya:

redis-cli config get maxmemory-policy

Con noeviction, una instancia llena deja de aceptar escrituras y responde con esto:

(error) OOM command not allowed when used memory > 'maxmemory'.

Esta única línea representa el peor modo de fallo de esta guía, porque el sitio no se cae. Se vuelve más lento. Cada escritura de caché falla, por lo que WordPress vuelve a consultar la base de datos para obtener el valor. Después intenta almacenarlo de nuevo en la siguiente petición y vuelve a fallar. El sitio ahora realiza todo el trabajo original de la base de datos más un viaje de ida y vuelta a Redis por cada clave. El panel de administración de WordPress no indica que esto esté ocurriendo. La cadena aparece en el registro de errores de PHP, así que busque OOM command not allowed con grep cuando un sitio se vuelva más lento después de añadir una caché.

allkeys-lru es el valor predeterminado adecuado en este caso. Redis elimina la clave usada menos recientemente cuando la memoria escasea. Esto es exactamente lo que necesita una caché de objetos, porque cada valor almacenado en ella es una copia de datos que aún existen en MySQL. Perder una clave cuesta una consulta. Rechazar una escritura cuesta todas las consultas, en cada petición, hasta que alguien lo detecta.

Evite las políticas volatile-* para este trabajo. Sólo tienen en cuenta las claves que tienen una caducidad, y Redis documenta que se comportan como noeviction cuando ninguna clave tiene una. WordPress almacena la mayoría de las entradas de la caché de objetos sin TTL, por lo que volatile-lru en una caché de objetos puede llenarse y empezar a rechazar escrituras. allkeys-lfu es una alternativa razonable si el tráfico accede con mucha frecuencia a un conjunto reducido de claves, ya que desaloja por frecuencia en lugar de por uso reciente. Elija una de forma deliberada y anote el motivo.

Persistencia: desactívela salvo que tenga un motivo

El redis.conf incluido habilita las instantáneas RDB con líneas como save 900 1 y deja desactivado el archivo de solo anexado. En una caché de objetos pura, las instantáneas no aportan nada. Los datos se pueden regenerar por definición, y una caché restaurada desde un archivo de hace veinte minutos contiene valores obsoletos en los que WordPress confiará.

Las instantáneas también tienen un coste. BGSAVE bifurca el proceso, y la copia en escritura puede hacer que el uso de memoria aumente considerablemente mientras el proceso hijo escribe. En un VPS pequeño, esto aparece en el registro de Redis:

Can't save in background: fork: Cannot allocate memory

Y a menudo aparece también esta advertencia durante el arranque. Redis indica que la bifurcación probablemente fallará más adelante:

WARNING overcommit_memory is set to 0! Background save may fail under low memory condition.

Para desactivar las instantáneas, establezca una programación de guardado vacía en /etc/redis/redis.conf, reinicie y confirme que el valor vuelva a estar vacío.

save ""

sudo systemctl restart redis-server
redis-cli config get save

Mantenga la persistencia sólo si la misma instancia contiene algo que no pueda reconstruir, como una cola de trabajos o contadores de límites de tasa. En ese caso, separe ambas funciones. Una caché necesita expulsar claves, mientras que los datos persistentes necesitan conservarlas, y maxmemory junto con la expulsión se aplica a toda la instancia, no a un índice de base de datos concreto. Dos instancias en dos sockets son la solución más limpia.

Instale el plugin y comprenda el drop-in

wp plugin install redis-cache --activate
wp redis enable
wp redis status

wp redis enable muestra Object cache enabled. cuando termina correctamente. En realidad, copia wp-content/plugins/redis-cache/includes/object-cache.php en wp-content/object-cache.php. Esa copia es el drop-in, y el drop-in es el componente que realiza el trabajo. WordPress carga wp-content/object-cache.php muy pronto, antes de ejecutar el código de cualquier plugin. Por eso la caché está disponible durante toda la petición. Un plugin activo sin un drop-in instalado no almacena nada en la caché.

Los mensajes de error indican qué parte falló. Object cache could not be enabled. significa que la copia falló, por lo que wp-content no permite escribir al usuario que ejecuta WP-CLI. A foreign object cache drop-in was found. significa que otro plugin de caché ya usa ese nombre de archivo, y la solución es wp redis update-dropin. Un mensaje que termina en Redis server is unreachable: seguido del error del cliente indica que la configuración de conexión es incorrecta. Vuelva a redis-cli ping.

Si la copia falló por permisos, coloque el archivo manualmente y asígnelo al usuario del servidor web.

cp wp-content/plugins/redis-cache/includes/object-cache.php wp-content/object-cache.php
sudo chown www-data:www-data wp-content/object-cache.php

Eliminar el plugin no elimina el drop-in. Ejecute primero wp redis disable, que muestra Object cache disabled. y elimina el archivo. Si elimina el directorio del plugin y deja el drop-in, el sitio seguirá ejecutando código de caché antiguo sin ningún plugin que lo actualice.

Ajustes de conexión en wp-config.php

Añada estas líneas antes de la línea que contiene /* That's all, stop editing! */, porque las constantes definidas después se cargan demasiado tarde.

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_DATABASE', 0 );
define( 'WP_REDIS_PREFIX', 'shop_prod:' );

Para el socket Unix, establezca el esquema y la ruta. El host y el puerto se ignoran en ese caso.

define( 'WP_REDIS_SCHEME', 'unix' );
define( 'WP_REDIS_PATH', '/run/redis/redis-server.sock' );
define( 'WP_REDIS_PREFIX', 'shop_prod:' );

WP_REDIS_MAXTTL fuerza una caducidad para cada clave, en segundos. No es necesario usarlo con allkeys-lru y resulta útil si quiere establecer un límite máximo estricto para la antigüedad de un valor almacenado en caché.

Un Redis, varios sitios: prefijos y bases de datos

Redis proporciona dieciséis bases de datos numeradas de forma predeterminada y un espacio de claves plano dentro de cada una. Dos instalaciones de WordPress configuradas para usar la base de datos 0 sin prefijo escriben los mismos nombres de clave en el mismo espacio. Por tanto, un sitio puede leer las opciones del otro y servirlas. Asigne a cada sitio su propio prefijo.

define( 'WP_REDIS_PREFIX', 'shopA_prod:' );
define( 'WP_REDIS_DATABASE', 1 );

El prefijo separa los nombres de las claves. El índice de la base de datos separa los espacios de claves. Esto es importante al vaciar una base de datos: vaciar un índice no afecta a los demás. El plugin también documenta WP_REDIS_SELECTIVE_FLUSH, que elimina sólo las claves que coinciden con su prefijo en lugar de eliminar toda la base de datos, aunque debe buscarlas mediante un escaneo.

Los prefijos y los índices no separan la memoria. maxmemory y la política de desalojo se aplican a toda la instancia. Por tanto, un sitio con mucha actividad puede expulsar las claves de otro sitio menos activo, y ninguno de los dos lo notifica. Los sitios que no deben afectarse entre sí necesitan instancias de Redis independientes, cada una con su propio socket y su propio límite.

Mantenga la caché de staging fuera de producción

Un sitio de staging suele ser una copia de los archivos y la base de datos de producción. Esto significa que también es una copia de wp-config.php, con el mismo prefijo y el mismo índice de base de datos. Si lo conecta al mismo Redis, escribirá las claves de producción con valores de staging. Un precio de prueba o una opción modificada aparecerá entonces en el sitio activo sin ningún despliegue ni registro que lo indique.

Separe cada entorno manualmente. En el archivo wp-config.php de staging:

define( 'WP_REDIS_PREFIX', 'shop_staging:' );
define( 'WP_REDIS_DATABASE', 5 );

Es preferible que staging tenga su propia instancia de Redis o que no use ninguna caché de objetos. define( 'WP_REDIS_DISABLED', true ); desactiva la caché en tiempo de ejecución y mantiene instalado el drop-in. También es la forma más rápida de comprobar si un error está relacionado con la caché.

Los tutoriales antiguos establecen WP_CACHE_KEY_SALT para este fin. El archivo readme del plugin indica que esa constante está obsoleta y que se sustituyó por WP_REDIS_PREFIX. Use el nombre nuevo.

Verifíquelo en lugar de confiar en él

Empiece con los diagnósticos del propio plugin.

wp redis status

La línea más importante es Drop-in. Drop-in: Valid indica que WordPress está cargando el archivo de este plugin. Drop-in: Not installed indica que la copia nunca se realizó y que el sitio no tiene una caché persistente, aunque la pantalla de administración aparezca en verde. Status informa de la conexión y Client identifica la extensión en uso. Ahí debe confirmar que se usa PhpRedis en lugar de Predis.

Después, pregunte directamente al núcleo de WordPress, porque no depende de lo que crea el plugin.

wp eval 'var_dump( wp_using_ext_object_cache() );'

bool(true) indica que el núcleo se comunica con una caché de objetos externa.

A continuación, demuestre que las claves llegan con el prefijo que configuró.

redis-cli -n 0 dbsize
redis-cli -n 0 --scan --pattern 'shop_prod:*' | head

El aumento de dbsize mientras navega por el sitio es la prueba. Cero claves con un drop-in válido significa que la conexión falla de forma silenciosa o que el prefijo no es el que cree.

Por último, revise las métricas que Redis proporciona.

redis-cli info stats | grep -E 'keyspace_hits|keyspace_misses|evicted_keys|expired_keys'

La tasa de aciertos es keyspace_hits / (keyspace_hits + keyspace_misses), y la documentación de Redis proporciona esa fórmula. Interprétela teniendo en cuenta dos aspectos. Los contadores abarcan toda la instancia desde su último reinicio, por lo que combinan todos los sitios y aplicaciones que la comparten. Además, la proporción justo después de vaciar la caché o reiniciar no tiene significado, porque la caché todavía se está llenando. Déjela funcionar durante un día normal de tráfico.

No compare su cifra con una tasa de aciertos ni con un recuento de consultas publicados por una empresa de hosting. Esos datos describen sus sitios y su conjunto de plugins. La cifra importante es la suya, medida antes y después en una página que una caché de páginas no pueda servir.

curl -o /dev/null -s -w '%{time_starttransfer}\n' -b cookies.txt https://example.com/my-account/

Ejecútelo con un almacén de cookies autenticado, varias veces, con la caché desactivada (WP_REDIS_DISABLED) y después activada. Esa diferencia es su resultado.

Cuándo Redis ralentiza WordPress

Una instancia llena con una política incorrecta es el caso principal, descrito arriba: OOM command not allowed when used memory > 'maxmemory'. en el registro, y un sitio que paga tanto por la base de datos como por la caché.

Redis en otro host es el segundo caso. WordPress realiza cientos de llamadas a la caché de objetos en una sola petición. Si una petición realiza 500 llamadas y cada ida y vuelta cuesta 1 ms, se pierde medio segundo esperando, algo que no ocurriría con un socket local. Mantenga Redis en el mismo equipo o en una red privada con una latencia inferior a un milisegundo.

Una tabla de opciones con demasiadas opciones cargadas automáticamente es el tercer caso, y es habitual en sitios antiguos. WordPress almacena todas las opciones cargadas automáticamente como una sola clave, por lo que un megabyte de datos atraviesa la conexión en cada petición. Mida su tamaño:

wp db query "SELECT ROUND(SUM(LENGTH(option_value))/1024) AS kb FROM wp_options WHERE autoload IN ('yes','on','auto','auto-on');"

WordPress 6.6 añadió nuevos valores de carga automática, por lo que una consulta antigua que sólo coincida con 'yes' subestima el valor en una instalación moderna. Todo lo que supere un megabyte es un problema que debe corregirse en la tabla de opciones, no en Redis.

Un reinicio vacía todo, por lo que los minutos posteriores a systemctl restart redis-server contienen sólo fallos de caché y trabajo de base de datos. Reinicie cuando haya poco tráfico. Además, una caché de objetos no impide que wp-cron.php se ejecute al cargar las páginas de los visitantes, lo que constituye otra fuente de peticiones lentas: traslade WP-Cron a una tarea real de cron del sistema mientras realiza estos cambios.

Mantenimiento

Limpie la caché después de un despliegue que cambie opciones o código del tema con wp cache flush. Ejecute wp redis update-dropin después de actualizar un plugin si el drop-in no se actualizó por sí solo, porque un drop-in de una versión anterior del plugin utilizado con una versión más reciente puede causar comportamientos anómalos. Supervise un servidor en producción con redis-cli --stat, que muestra una línea por segundo. redis-cli monitor muestra cada comando y consume CPU real en una instancia con mucha carga, así que úselo durante unos segundos mientras reproduce un problema y deténgalo después.

Hay otra cifra que conviene conocer: redis-cli info clients informa de connected_clients. PHP-FPM mantiene una conexión por worker, por lo que esa cifra debería corresponderse con pm.max_children, no superarlo en un orden de magnitud. Si lo supera, algo está abriendo conexiones y no las está cerrando.

FAQ

¿Sigue siendo necesaria una caché de páginas si uso una caché de objetos Redis?

Sí, para el tráfico anónimo. Una caché de páginas sirve HTML almacenado sin ejecutar PHP, lo que siempre consume menos recursos que ejecutar WordPress con una caché de objetos activa. La caché de objetos gestiona las peticiones que la caché de páginas debe omitir: usuarios autenticados, carritos, pagos y wp-admin. En una tienda o un sitio de membresía, merece la pena usar ambas. En un sitio cuyos visitantes nunca inician sesión, la caché de páginas realiza casi todo el trabajo.

¿Cuánta memoria debo asignar a Redis para WordPress?

Calcúlela a partir de su propio servidor en lugar de copiar una cifra. Tome la RAM total, reste el buffer pool de MySQL y los buffers por conexión, reste pm.max_children multiplicado por el tamaño residente de un worker de PHP-FPM y reste unos cientos de megabytes para el kernel y el servidor web. Asigne a Redis una parte de lo que quede. Después, compruebe used_memory_human en redis-cli info memory tras un día de tráfico y ajuste el valor. Un único sitio de WordPress suele estabilizarse en unas decenas de megabytes, por lo que un maxmemory de 256 MB es un punto de partida holgado en un servidor de 4 GB.

¿Por qué mi sitio se volvió más lento después de activar la caché de objetos Redis?

La causa habitual es una instancia llena que usa la política noeviction. Redis rechaza las nuevas escrituras y devuelve OOM command not allowed when used memory > 'maxmemory'., por lo que WordPress vuelve a consultar la base de datos para cada valor y, además, incurre en un viaje de ida y vuelta innecesario a Redis. Compruebe redis-cli config get maxmemory-policy, establezca allkeys-lru y confirme que maxmemory no sea demasiado pequeño. Otras causas habituales son un servidor Redis en un host remoto, donde cientos de viajes de ida y vuelta por petición se acumulan, y un valor de opciones cargadas automáticamente de varios megabytes que atraviesa la conexión en cada petición.

¿Pueden varios sitios de WordPress compartir un servidor Redis?

Sí, si se hace con cuidado. Asigne a cada sitio un WP_REDIS_PREFIX único para que los nombres de las claves no colisionen, y un índice WP_REDIS_DATABASE independiente para que vaciar la caché de un sitio no borre la de otro. Lo que siguen compartiendo es la memoria: maxmemory y la expulsión se aplican a toda la instancia, por lo que un sitio con mucha actividad puede expulsar las claves de otro con poca actividad. Los sitios que no deben afectarse entre sí necesitan instancias Redis independientes con sus propios límites.

¿Es seguro eliminar wp-content/object-cache.php?

Sí. Es un drop-in, no forma parte del núcleo de WordPress, y eliminarlo devuelve WordPress a su caché integrada por petición. El sitio sigue funcionando y simplemente realiza más consultas a la base de datos. Prefiera wp redis disable, que elimina el archivo correctamente e informa de Object cache disabled.. Eliminarlo manualmente es la medida de emergencia adecuada si Redis está caído o funciona de forma incorrecta y no puede acceder al área de administración.