Redis como caché de objetos de WordPress en un VPS

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. Así, la siguiente petición los lee desde Redis en lugar de volver a solicitarlos a MySQL. WordPress ya incluye una caché de objetos en el núcleo, WP_Object_Cache, pero funciona en la memoria de PHP y se descarta cuando termina la petición. Un archivo drop-in la sustituye por otra que se comunica con Redis. De este modo, la caché se conserva entre peticiones.

La caché de objetos no es una caché de páginas. Esta diferencia determina si esta guía le resulta útil. Una caché de páginas almacena el HTML terminado de una URL y lo sirve de nuevo sin ejecutar PHP. Es más rápida que cualquier operación que pueda hacer Redis y funciona para los visitantes que no han iniciado sesión. Cuando 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: bootstrap, 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, checkout y wp-admin. En una tienda WooCommerce, ese es el tráfico más costoso.

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

Hay un límite importante que debe conocer antes de empezar. Una caché de objetos no acelera una consulta lenta. Evita repetir una consulta que ya se ejecutó. La primera petición después de un fallo de caché tiene el coste completo. Por tanto, un plugin que ejecuta una consulta sin índices todavía la ejecutará una vez durante cada período de vida de la caché.

Qué necesita primero

• Un VPS Linux con una shell y sudo. No se necesita ningún panel de control.
• WordPress servido por PHP-FPM, por ejemplo, en una pila LAMP en Ubuntu 24.04.
• WP-CLI instalado en el servidor. Todos los pasos tienen un equivalente en la pantalla de administración, pero la versión con shell es más rápida.
• Redis en el mismo equipo que PHP. La latencia es el objetivo principal y un salto de red la elimina.

Los comandos siguientes están escritos para Ubuntu 24.04 con PHP 8.3 y el usuario web www-data. Ajuste la versión de PHP y el usuario para que coincidan con 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 debe 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 completamente en PHP, y el plugin la usa automáticamente cuando está disponible. PHP-FPM carga las extensiones al iniciar. Una extensión nueva 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, que es suficiente para una caché de objetos. Si necesita 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 después del cambio de licencia de 2024, utiliza el mismo protocolo y todo lo siguiente se aplica sin cambios.

Vincule Redis para impedir cualquier acceso externo

Redis no tiene 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 están en el mismo equipo, un socket Unix es preferible a TCP mediante loopback. No hay una pila TCP en el trayecto, y el acceso se decide mediante permisos de archivo en lugar de una regla de 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 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, ya que un error tipográfico podría dejar ambas vías inutilizables al mismo tiempo.

¿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. En un servidor WordPress, suele ser MySQL. journalctl -k | grep -i "out of memory" muestra ese cierre después de que ocurre. 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. En un sitio con muchos plugins, suele ser de 64 MB a 128 MB. El kernel y el servidor web necesitan unos cientos de megabytes. Lo que queda es su límite máximo. Redis recibe una parte de esa cantidad.

Ahora mida en lugar de hacer una estimación. 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. MySQL 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 ahora mismo y se pierde en el siguiente reinicio. Es la misma trampa que un sysctl -w sin más. Edite el archivo, después 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 igual. Un límite de cgroup termina el proceso en lugar de expulsar una clave. Si Redis se ejecuta en un contenedor junto a WordPress, debe usar la misma cifra en los límites de memoria del archivo Compose. 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 lo siguiente:

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

Esa ú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 en la 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 asume ahora todo el trabajo original de la base de datos, además de un viaje de ida y vuelta a Redis por cada clave. Nada en el panel de administración de WordPress 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 descarta la clave usada menos recientemente cuando queda poca memoria. Esto es exactamente lo que necesita una caché de objetos, porque cada valor almacenado en ella es una copia de datos que todavía 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 incluyen una caducidad, y Redis documenta que se comportan como noeviction cuando ninguna clave tiene caducidad. WordPress almacena la mayoría de las entradas de la caché de objetos sin TTL, por lo que volatile-lru puede llenarse en una caché de objetos y empezar a rechazar escrituras. allkeys-lfu es una alternativa razonable si el tráfico alcanza con mucha frecuencia un conjunto reducido de claves, ya que desaloja según la frecuencia y no según el uso reciente. Elija una opción deliberadamente y documente el motivo.

Persistencia: déjela desactivada 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 adición. Para una caché de objetos pura, las instantáneas no aportan nada. Por definición, los datos se pueden regenerar, y una caché restaurada desde un archivo de hace veinte minutos contiene valores obsoletos que WordPress usará como válidos.

Las instantáneas también tienen un coste. BGSAVE bifurca el proceso, y el mecanismo copy-on-write puede aumentar mucho el uso de memoria 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 también aparece 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 un programa de guardado vacío 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 almacena algo que no puede reconstruir, como una cola de trabajos o contadores de límites de tasa. En ese caso, separe ambas funciones. Una caché necesita expulsar claves y los datos persistentes necesitan conservarlas, pero maxmemory y la expulsión se aplican a toda la instancia, no a un índice de base de datos concreto. La solución limpia es usar dos instancias en dos sockets.

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. si la operación se completa 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 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 utiliza ese nombre de archivo, y la solución es wp redis update-dropin. Si un mensaje termina en Redis server is unreachable: y después aparece el error del cliente, la configuración de conexión es incorrecta. Vuelva a redis-cli ping.

Si la copia falló por los permisos, colóquela manualmente y asígnela 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. Este comando muestra Object cache disabled. y elimina el archivo. Si elimina el directorio del plugin mientras el drop-in permanece, el sitio seguirá ejecutando código antiguo de caché y no habrá ningún plugin que lo actualice.

Ajustes de conexión en wp-config.php

Añada estas líneas encima 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 usar 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 lo necesita con allkeys-lru. Es ú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 que usan la base de datos 0 sin prefijo escriben los mismos nombres de clave en el mismo espacio. Por eso, 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 el prefijo, en lugar de eliminar toda la base de datos. Para encontrarlas, debe recorrer las claves.

Los prefijos y los índices no separan la memoria. maxmemory y la política de expulsión se aplican a toda la instancia. Por eso, un sitio con mucha actividad puede expulsar las claves de otro sitio inactivo, sin que ninguno de los dos lo notifique. Los sitios que no deben afectarse entre sí necesitan instancias de Redis separadas, 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. Por tanto, 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.

Asigne una sal distinta a cada entorno manualmente. En el 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é durante la ejecución y mantiene instalado el drop-in. También es la forma más rápida de comprobar si un error se debe o no a la caché.

Los tutoriales antiguos establecen WP_CACHE_KEY_SALT para esto. El readme del plugin marca esa constante como obsoleta y la sustituye por WP_REDIS_PREFIX. Use el nombre nuevo.

Verifíquelo en lugar de confiar en él

Empiece por los diagnósticos del propio plugin.

wp redis status

La línea más importante es Drop-in. Drop-in: Valid significa que WordPress está cargando el archivo de este plugin. Drop-in: Not installed significa 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 indica la extensión en uso. Ahí debe confirmar que se usa PhpRedis y no Predis.

Después, consulte directamente a WordPress core, porque no depende de lo que crea el plugin.

wp eval 'var_dump( wp_using_ext_object_cache() );'

bool(true) significa que core está comunicándose con una caché de objetos externa.

A continuación, compruebe que llegan claves 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 está fallando silenciosamente 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 precauciones. Los contadores abarcan toda la instancia desde el ú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 significa nada, 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 o un recuento de consultas publicado por una empresa de hosting. Esos datos describen sus sitios y su conjunto de plugins. La cifra relevante 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/

Ejecute esto con un almacén de cookies autenticado varias veces, primero con la caché desactivada (WP_REDIS_DISABLED) y después activada. Esa diferencia es el resultado.

Cuando Redis ralentiza WordPress

Una instancia llena con una política incorrecta es el problema principal, explicado 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 problema. 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. Un socket local no tendría ese coste. Mantenga Redis en el mismo servidor o en una red privada con una latencia inferior a un milisegundo. La ganancia que obtiene el caso del mismo servidor gracias al kernel es otra cuestión: la planificación con conocimiento de la caché añadida en Linux 7.2 intenta mantener procesos comunicativos, como PHP-FPM y Redis, en núcleos que comparten una caché. Un huésped VPS obtiene menos ventajas de esto que un servidor físico.

Una tabla de opciones con demasiados valores cargados automáticamente es el tercer problema. 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. Mídalo:

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 eso, una consulta antigua que sólo busca 'yes' subestima el tamaño en una instalación moderna. Todo valor superior a un megabyte debe corregirse en la tabla de opciones, no en Redis.

Un reinicio vacía todo. Por tanto, los minutos posteriores a systemctl restart redis-server contienen sólo fallos de caché y operaciones de base de datos. Reinicie cuando el tráfico sea bajo. Además, una caché de objetos no impide que wp-cron.php se ejecute al cargar las páginas de los visitantes. Esto también puede ralentizar las peticiones: traslade WP-Cron a una tarea real de cron del sistema mientras realiza estos cambios.

Tareas de mantenimiento

Vacía la caché después de un despliegue que cambie opciones o código del tema con wp cache flush. Ejecuta 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 frente a un plugin más reciente es una causa real de comportamientos extraños. Supervisa un servidor en producción con redis-cli --stat, que muestra una línea por segundo. redis-cli monitor muestra todos los comandos y consume CPU real en una instancia con mucha carga, así que úsalo durante unos segundos mientras reproduces un problema y detenlo después.

Hay otro valor 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 aproximarse a tu 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 solicitudes que la caché de páginas debe omitir: usuarios con sesión iniciada, carritos, pago 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 trabajador de PHP-FPM y reste unos cientos de megabytes para el kernel y el servidor web. Asigne a Redis una parte de lo que queda y, después de un día de tráfico, compruebe used_memory_human en redis-cli info memory y ajuste el valor. Un único sitio de WordPress suele estabilizarse en 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 que la instancia está llena y usa la política noeviction. Redis rechaza las escrituras nuevas y devuelve OOM command not allowed when used memory > 'maxmemory'., por lo que WordPress recurre a la base de datos para cada valor y, además, añade 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 solicitud terminan acumulándose, y un valor de opciones cargadas automáticamente de varios megabytes que atraviesa la conexión en cada solicitud.

¿Pueden varios sitios de WordPress compartir un servidor Redis?

Sí, con precauciones. Asigne a cada sitio un WP_REDIS_PREFIX único para que los nombres de las claves no colisionen y un índice WP_REDIS_DATABASE separado para que vaciar la caché de un sitio no vacíe 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 un sitio con poca actividad. Los sitios que no deben afectarse entre sí necesitan instancias Redis separadas 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 solicitud. El sitio sigue funcionando y simplemente realiza más consultas a la base de datos. Es preferible usar 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.