Un caché de objetos persistente puede evitar el trabajo repetido de la base de datos, pero cada operación de caché también tiene un costo. Un servicio Redis remoto con latencia de red, valores en caché de gran tamaño o desalojos frecuentes puede hacer que las páginas simples sean más lentas, mientras que las páginas complejas mejoran.
Compare las mismas rutas de solicitud con mediciones controladas en lugar de asumir que la caché de objetos siempre es beneficiosa.
Aclarar qué hace el caché de objetos
La caché de objetos almacena objetos de WordPress, resultados de consultas y valores generados por plugins entre solicitudes. No es lo mismo que el caché de página completa: PHP aún se ejecuta y ensambla la página.
Una página de inicio almacenada en caché puede no mostrar ninguna diferencia porque el HTML de página completa omite PHP por completo. Las páginas de inicio de sesión, las solicitudes de API, la búsqueda y el pago pueden revelar el comportamiento de la caché de objetos con mayor claridad.
Confirme el drop-in recurso en wp-content/object-cache.php y el servicio al que se conecta. No edite ni elimine el plugin sin realizar una reversión y sin conocer el plugin propietario.
Construir comparaciones representativas
Elija errores de caché públicos, tareas del panel de inicio de sesión, consultas del catálogo de WooCommerce y cualquier ruta reportada como lenta. Registre varias muestras con la caché de objetos en buen estado.
En preparación o en una ventana de mantenimiento, desactívelo a través del método admitido por el proveedor y repita con datos y carga similares. Compare el tiempo total de respuesta, el tiempo de consulta de la base de datos y el tiempo de caché externo.
Una solicitud rápida después de la desactivación no es prueba. Los cachés de bases de datos fríos y los valores de objetos calentados hacen que la secuencia sea importante.
Medir la latencia y los errores de conexión
Si Redis o Memcached están en otro host, los pequeños retrasos en la red se multiplican en muchas operaciones. Revise los diagnósticos del plugin y los registros del servidor para detectar tiempos de espera, reconexiones o fallas de autenticación.
Desde un servidor autorizado, las herramientas del proveedor pueden medir la latencia de ida y vuelta y el estado del servicio. No exponga el puerto de caché públicamente ni debilite la autenticación para ejecutar una prueba.
Configure tiempos de espera conservadores para que una interrupción de la caché no retenga cada solicitud de PHP durante unos segundos antes de retroceder.
Busque valores enormes y grupos abusivos
Un plugin puede almacenar en caché una matriz grande y recuperarla o serializarla en cada solicitud. Inspeccione las métricas de caché por tamaño de clave o grupo cuando sea compatible, teniendo cuidado de no registrar valores confidenciales.
Las señales de advertencia comunes incluyen opciones muy amplias, respuestas API completas, combinaciones de consultas ilimitadas y una clave de caché única por visitante.
Repare el plugin propietario o la estrategia clave. El aumento de la memoria caché puede posponer el desalojo, pero no corrige un diseño ilimitado.
Verifique el desalojo y la presión de la memoria
Cuando el caché alcanza su límite de memoria, la política de desalojo determina qué claves desaparecen. Una tasa de aciertos baja con desalojo constante puede añadir una sobrecarga de caché y al mismo tiempo enviar el trabajo a MySQL.
Revise la memoria utilizada, las claves desalojadas, las proporciones de aciertos y errores y el tiempo de actividad durante un período significativo. Un reinicio del servicio restablece los contadores, así que tenga en cuenta la ventana de observación.
No ejecute comandos de lista de claves amplia en una caché de producción ocupada. Utilice estadísticas sin bloqueo y herramientas de proveedores.
Separe los datos persistentes de los no persistentes
Algunos valores no son adecuados para compartir entre solicitudes o sitios. En WordPress multisitio, los prefijos y los números de la base de datos deben evitar colisiones. Los datos de autenticación, nonce o relacionados con la sesión requieren una caducidad correcta.
Si solo un plugin o grupo se comporta mal, configure un grupo no persistente compatible o repare su lógica de almacenamiento en caché en lugar de deshabilitar el caché de objetos para toda la instalación.
Los lavados deben tener un alcance. Una base de datos Redis completa puede servir a más de una aplicación.
Verificar el comportamiento de falla
Simule temporalmente la indisponibilidad del servicio solo en preparación. WordPress debería fallar correctamente en la operación respaldada por la base de datos en lugar de producir un error fatal o un tiempo de espera de varios segundos.
Después de cualquier cambio de configuración, pruebe los errores públicos, la edición administrativa, los formularios, las tareas programadas y el pago. Supervise la carga de MySQL y el tiempo de respuesta de PHP; mover la latencia de Redis a la base de datos no es una mejora.
Solicite una evaluación cuando las métricas muestren reconexiones, desalojos o valores elevados, o cuando solo determinadas rutas retrocedan. Proporcionar estadísticas de caché y tiempos desinfectados; no comparta claves, contraseñas ni datos del cliente en la consulta inicial.