Índice de aciertos de la caché de objetos de WordPress: relevancia y valores objetivo recomendados

Qué almacena la caché de objetos de WordPress

El Caché de objetos de WordPress almacena datos bajo una clave y dentro de un grupo. Si WordPress vuelve a solicitar el mismo valor, puede obtenerlo de la caché en lugar de volver a realizar el trabajo subyacente. Esto incluye, por ejemplo, datos que, de otro modo, habría que leer de la base de datos o volver a calcular.

La implementación de Core integrada viene por defecto vinculado a la solicitud: Mantiene sus entradas durante una sola solicitud. Por lo tanto, una visita posterior a la página no tiene acceso automático a los valores almacenados anteriormente. No obstante, la caché puede evitar accesos repetidos incluso dentro de una misma solicitud.

Un «drop-in» puede sustituir la implementación principal por un Caché de objetos persistente sustituir. De este modo, las entradas adecuadas pueden conservarse más allá de las solicitudes individuales. Redis es una posible opción de backend, pero no es un requisito imprescindible para WordPress; también son posibles otros enfoques de backend. Incluso con un «drop-in» persistente, determinados grupos pueden seguir siendo válidos únicamente para la solicitud actual.

Los datos transitorios son otra forma de almacenar datos que se necesitan durante un tiempo limitado. Con una caché de objetos persistente, se pueden guardar allí, en lugar de hacerlo normalmente en la base de datos. Su tiempo de vigencia no implica una disponibilidad mínima garantizada: un valor puede desaparecer antes. Por lo tanto, el código de la aplicación debe contar con la posibilidad de que un transitorio falte y poder regenerar el valor si es necesario.

Esta distinción es fundamental para evaluar posteriormente la tasa de aciertos: el acceso a la caché local durante una solicitud y el acceso a un backend externo no son necesariamente el mismo parámetro de medición. Por lo tanto, comprueba primero qué implementación se utiliza realmente y qué datos almacena de forma persistente.

Diferencias entre la caché de objetos y la caché de páginas

Al acceder a una página, puede que un Caché de página servir una respuesta de página ya generada. Si la solicitud se responde allí, no es necesario que recorra la misma ruta de la aplicación de WordPress que una solicitud no almacenada en caché. La caché de objetos, por el contrario, funciona dentro de la aplicación con datos almacenados en caché de forma individual, no con la respuesta completa de la página.

Imagina una página de artículo accesible al público: si su respuesta se encuentra en la caché de páginas, se puede servir directamente. Sin embargo, si WordPress tiene que generar la página, la caché de objetos puede ayudar en caso de accesos repetidos a los datos. El trabajo que realmente se ahorra depende de la solicitud, de las entradas almacenadas y de la implementación concreta.

Esto tiene consecuencias para la interpretación: una buena tasa de caché de objetos solo describe los accesos a la caché registrados. No indica directamente cuántos visitantes ya han recibido una respuesta lista en la caché de páginas ni cuán rápido responde el sitio web en su conjunto. Cuando el almacenamiento en caché de páginas es intenso, las ventajas de la caché de objetos pueden hacerse evidentes sobre todo en las solicitudes restantes de WordPress.

La caché del navegador y la caché de código OP también cumplen otras funciones. La caché del navegador almacena recursos para el visitante; una caché de código OP de PHP almacena código PHP compilado. Ninguna de las dos sustituye al almacenamiento de datos concretos de la aplicación en la caché de objetos ni a la entrega de una respuesta completa desde una caché de página.

La constante WP_CACHE Por sí solo, no activa la caché de objetos de Redis. Para disponer de una caché de objetos persistente, necesitas una implementación adecuada y su configuración correspondiente. Encontrarás un ejemplo adicional sobre la interacción entre varios niveles en el artículo sobre la Motor de caché de AccelerateWP.

Qué nos dicen los aciertos y los errores

A Hit se da cuando se encuentra una entrada buscada en el nivel de caché en cuestión. Un Srta. significa que no se encuentra allí. La tasa de aciertos calcula la relación entre los aciertos y el total de aciertos y fallos registrados: aciertos / (aciertos + fallos) × 100. Si no hay ni aciertos ni fallos, la tasa para ese periodo no está definida.

Un error no es necesariamente un fallo técnico. Es posible que una entrada aún no esté disponible en el primer intento de acceso; incluso tras su caducidad, puede que sea necesario volver a obtenerla o generarla. Lo decisivo es qué consecuencias tienen esos intentos fallidos en el proceso concreto y si tiene sentido repetir los accesos.

El método «Core» de WordPress cuenta, en su propia implementación, los aciertos en la caché y los intentos fallidos. Sin embargo, un complemento «drop-in» puede sustituir esta implementación. Por eso, a partir del recuento del núcleo no se puede deducir con certeza qué es lo que registra una visualización del complemento: comprueba, para la versión utilizada, qué visitas y qué periodo de tiempo abarca su cifra.

Redis muestra el siguiente mensaje: keyspace_hits y keyspace_misses búsquedas de claves exitosas o fallidas en el espacio de claves de Redis. También una búsqueda fallida EXISTS-La falta puede contar como una falta. Esta Índice de aciertos de Redis Por lo tanto, no debe equipararse automáticamente con una cuota de WordPress o de plugins.

Si una instancia de Redis da servicio a varios sitios web o aplicaciones, sus contadores pueden reflejar de forma conjunta el tráfico de todos ellos. En ese caso, sin una telemetría separada adecuada, no es posible asignar de forma fiable una cuota global a un único sitio web de WordPress. Por lo tanto, cada vez que realices una comparación, debes indicar a qué nivel y a qué instancia se refieren las cifras.

Comprobar cuidadosamente el área de medición y el acceso

Antes de realizar la medición, comprueba qué implementación de caché de objetos utiliza WordPress. Si dispones de WP-CLI y tienes acceso al directorio de WordPress, puedes iniciar un análisis de lectura con el siguiente comando:

wp cache type

El resultado ayuda a clasificar la implementación, pero no demuestra que todos los accesos relevantes se almacenen de forma persistente. WordPress permite que un complemento sustituya la caché del núcleo; al mismo tiempo, es posible que algunos grupos concretos no sean persistentes. Por lo tanto, anota también el complemento o plugin utilizado y su versión.

Consulta en la documentación de la versión concreta qué accesos incluyen sus «hits» y «misses» mostrados y durante qué periodo de tiempo se contabilizan. Solo se puede comparar de forma significativa la tasa de un plugin con otro indicador si se conocen el ámbito de medición y el método de recuento. Es especialmente importante saber si la visualización se refiere únicamente a una solicitud o a un intervalo de tiempo más amplio.

En el caso de Redis, siempre que se disponga de conexión y permisos, puedes consultar en modo lectura la información estadística y de memoria en una sesión de la CLI de Redis. Los siguientes comandos no incluyen datos de acceso de forma deliberada:

INFO stats
INFO memory

Documenta el Rango de medición: ¿Qué instancias o nodos se han consultado y qué otros sitios web o aplicaciones los utilizan? Los contadores globales de Redis no se pueden asignar fácilmente a un único sitio web cuando se comparten. Comprueba que los resultados no contengan información operativa sensible antes de compartirlos; para este inventario no es necesario realizar ni un vaciado ni una prueba de carga.

Si no tienes acceso a la CLI de Redis, pregunta a tu proveedor de alojamiento cuáles son las métricas disponibles y su ámbito de aplicación. Además, un panel de control solo resulta útil si queda claro si muestra la misma instancia, nodos individuales o valores ya agregados.

Calcular la tasa de aciertos de Redis en un intervalo

Las estadísticas de Redis son recuentos, no una conclusión definitiva sobre un periodo de medición concreto. Para realizar un análisis por intervalos, consulta los valores de keyspace_hits y keyspace_misses al inicio y al final del mismo intervalo de tiempo establecido por la misma instancia. Anota ambos momentos y la instancia correspondiente para que las lecturas coincidan.

A continuación, resta el valor inicial del valor final para cada contador. El Tasa de aciertos por intervalo es: ΔHits / (ΔHits + ΔMisses) × 100. El símbolo Δ representa la diferencia correspondiente. Si ambas diferencias son cero, no se han contabilizado consultas en esta ventana; en ese caso, la tasa no está definida, en lugar de ser del cero por ciento.

Un ejemplo ilustrativo de cálculo, no una medición: si las aciertos aumentan en 900 y los fallos en 100, el resultado es un 90 % sobre un total de 1.000 consultas contabilizadas. Esto no significa ni que las páginas sean un 90 % más rápidas, ni que se hayan ahorrado exactamente 900 consultas a la base de datos. Redis cuenta las consultas de claves; su importancia para la aplicación depende del acceso concreto.

Si alguno de los contadores retrocede entre dos lecturas, la diferencia simple calculada mediante esta fracción no es válida. Esto puede deberse a un reinicio o al restablecimiento de las estadísticas. Vuelve a iniciar el intervalo de medición o divídelo en el punto de ruptura basándote en datos de funcionamiento fiables, en lugar de introducir un valor negativo en la fórmula.

Si hay varios nodos, primero calcula las diferencias para cada nodo correspondiente durante el mismo periodo. A continuación, suma por separado los aciertos y los fallos y calcula a partir de ahí la tasa global. Una media no ponderada de los distintos porcentajes trata un nodo con pocas consultas igual que uno con muchas; esto puede distorsionar considerablemente la visión general.

Anota qué nodos se incluyen realmente y qué papel desempeñan en el entorno. Una tasa global calculada de este modo solo describe los contadores seleccionados y sus usuarios; no se traduce por sí sola en una cuota específica de la caché de objetos de WordPress.

Informe de mediciones e indicadores clave de Redis

Además de los aciertos y los errores, hay otros contadores de Redis que ayudan a contextualizar los datos. También en este caso, las diferencias observadas en el periodo seleccionado son más significativas que las cifras totales aisladas. La siguiente tabla distingue entre el significado de los valores y las conclusiones que estos no pueden sustentar por sí solos.

Un aumento de expired_keys puede ser motivo para analizar con más detalle los periodos de vigencia y los patrones de acceso. Sin embargo, no indica si una entrada se volvió a necesitar poco después de su vencimiento. Del mismo modo, evicted_keys considerarlo en el contexto del límite de almacenamiento configurado y la estrategia de desplazamiento, en lugar de deducir inmediatamente de ello un aumento del almacenamiento.

Un útil Informe de medición Indica el inicio y el final del intervalo de tiempo, la instancia o el nodo, las dos diferencias entre contadores, su suma y la cuota calculada. Añade si la instancia se comparte y si se tiene constancia de algún reinicio o restablecimiento durante el intervalo. De este modo, las mediciones serán trazables posteriormente.

Registra simultáneamente el tipo de solicitud en cuestión y un indicador de latencia adecuado para ella, así como la carga de la base de datos y la tasa de errores. Por ejemplo, distingue las visitas a páginas públicas de las solicitudes de usuarios registrados, si se dispone de datos pertinentes al respecto. La cuota de Redis por sí sola no revela cuál de estos tipos de solicitud se ha beneficiado de una coincidencia.

Para poder realizar una comparación posterior, el periodo, los nodos y la composición de las solicitudes deben ser lo más similares posible. Anota además los cambios relevantes y las fases de calentamiento detectables. Cuando falten datos o una instancia compartida no permita realizar una asignación, esta limitación debe incluirse en el informe, en lugar de en una conclusión aparentemente precisa.

Puesta en marcha, tienda y página web estática

Tras un reinicio o una implementación, es posible que, en un primer momento, falten algunas entradas necesarias. Es normal que se produzcan estas omisiones durante el llenado de la caché; con accesos repetidos, la tasa de aciertos puede aumentar posteriormente. Los valores de la Fase fría y fase caliente Deberías analizarlo por separado, para que una media a largo plazo no oculte ni los costes iniciales ni la evolución posterior.

En el caso de una tienda online o de un área de acceso restringido, las solicitudes dinámicas revisten especial interés: una caché de página no responde necesariamente a cada consulta del carrito de la compra o de la cuenta. Por lo tanto, compara tipos de solicitudes lo más similares posible y presta atención, además de a la tasa de aciertos, a sus tiempos de respuesta y a la carga de la base de datos. Una tasa de aciertos alta en Redis no indica por sí sola si el carrito de la compra se muestra rápidamente y con el contenido correcto.

En cambio, en una página web predominantemente estática, una gran parte de las visitas a las páginas ya puede proceder de la caché de páginas. En este caso, una caché de objetos persistente afecta sobre todo a las solicitudes que WordPress procesa realmente. Por lo tanto, evalúa por separado si estas solicitudes restantes se benefician de ello y si el efecto repercute en el conjunto de la página web.

Si utilizas Redis junto con otros sitios web o aplicaciones, el contador de instancias también incluirá sus accesos. Sin una telemetría separada adecuada, no es posible asignar de forma fiable la cuota global a un sitio web concreto. Documenta también qué nodos se tienen en cuenta: de lo contrario, un cambio en la cuota podría deberse igualmente a un uso diferente o a un cambio en el ámbito de medición.

Analizar los valores anómalos y los errores

Una tasa baja es, en primer lugar, una observación, no un diagnóstico. Entre las posibles explicaciones se encuentran un gran número de accesos iniciales, duraciones cortas o una distribución de accesos con claves que rara vez se reutilizan. Comprueba si ha cambiado la composición de las solicitudes o el intervalo de medición antes de ajustar la memoria o la configuración de la caché.

Los contadores expired_keys y evicted_keys proporcionan más información: el primero cuenta las claves caducadas, mientras que el segundo cuenta las claves que han sido desplazadas debido a la limitación de memoria. Sus diferencias dependen de la instancia de Redis y deben ajustarse a la configuración y al uso. El hecho de que haya muchas claves caducadas no demuestra ni que se haya elegido un TTL incorrecto ni que tenga sentido un tiempo de vida más largo; esto puede mermar la actualidad de los datos almacenados.

Para las ampliaciones propias, en wp_cache_get el parámetro $found Importante: distingue entre un valor encontrado y uno guardado false de una entrada que no se ha encontrado. Antes de realizar acciones relacionadas con grupos, deberías utilizar wp_cache_supports Comprobar si el backend concreto admite la función deseada. Una solución alternativa puede diferir de la implementación del núcleo.

Advertencia: Un vaciado de caché imprudente puede afectar a más entradas o aplicaciones de las previstas y distorsionar la siguiente medición debido a un arranque en frío. Aclara el alcance y obtén la autorización antes de llevar a cabo acciones de borrado. Puntos de partida adicionales para la Solución de problemas en una caché de objetos de WordPress lenta ayudar a incluir en el análisis también la posible sobrecarga de la caché.

Establecer por uno mismo unos valores objetivo razonables

Una cuota mínima universal del 90 % no es un requisito técnico sólido. Es más razonable establecer un rango objetivo específico para cada ubicación, que se ajuste a la distribución de accesos prevista y a las necesidades de la aplicación. Redis recomienda evaluar la cuota observada en el contexto del patrón de acceso correspondiente; un porcentaje por sí solo no explica el rendimiento de WordPress.

En primer lugar, realiza una medición inicial representativa que incluya el periodo, el rango de medición, el número de accesos y la tasa de respuesta. Para ello, registra los tiempos de respuesta de los tipos de solicitud más importantes, la carga de la base de datos y la tasa de errores. Identifica por separado los arranques en frío y ten en cuenta las diferencias típicas entre los periodos de poco y mucho tráfico, en lugar de considerar como estado normal una ventana de tiempo que, por casualidad, haya resultado favorable.

A continuación, planifica un cambio concreto y, una vez aprobado, pruébalo, a ser posible, primero en un entorno de pruebas adecuado. A continuación, compara periodos de tiempo y combinaciones de solicitudes similares: ¿cambian la cuota y el número de consultas, pero también la latencia o la carga de la base de datos? De este modo, se puede distinguir mejor el efecto de un mero desplazamiento de los accesos.

Incluso una tasa elevada puede ocultar unos pocos errores especialmente costosos. Por el contrario, una tasa moderada no tiene por qué suponer un problema si las consultas relevantes se responden de forma rápida y correcta. Los gastos operativos adicionales que supone Redis u otro backend persistente no se justifican automáticamente solo por una mejor tasa de respuesta; ten en cuenta la asistencia técnica del proveedor de alojamiento, los costes y los posibles escenarios de fallo.