Explicación del almacenamiento en caché

Descripción

Entorno
Experience Manager


 

Problema/Síntomas
Este documento explica cómo se produce el almacenamiento en caché de Dispatcher y cómo se puede configurar.


 

Tabla de contenido

Resolución

Directorios de almacenamiento en caché

Utilizamos los siguientes directorios de caché predeterminados en nuestras instalaciones de línea de base

  • Autor

    • /mnt/var/www/author
  • Editor

    • /mnt/var/www/html

Cuando cada solicitud atraviesa el despachante, las solicitudes siguen las reglas configuradas para mantener una versión en caché local de la respuesta de los elementos aptos.

Nota:

Intencionalmente mantenemos la carga de trabajo publicada separada de la carga de trabajo del autor porque cuando Apache busca un archivo en DocumentRoot, no sabe de qué instancia AEM vino. Por lo tanto, incluso si tiene la caché deshabilitada en la granja de autores, si el DocumentRoot del autor es el mismo que el del editor, servirá archivos de la caché cuando estén presentes. Lo que significa que servirá archivos de autor de la caché publicada y proporcionará a sus visitantes una experiencia de combinación realmente horrible. Mantener directorios DocumentRoot separados para diferentes contenidos publicados también es una mala idea. Tendrá que crear varios elementos en caché que no difieran entre sitios como clientlibs, así como tener que configurar un agente de vaciado de replicación para cada DocumentRoot que configure, lo que aumenta la cantidad de sobrecarga de vaciado con cada activación de página. Confíe en el espacio de nombres de los archivos y en sus rutas en caché completas y evite múltiples DocumentRoots para los sitios publicados.

Archivos de configuración

Dispatcher controla lo que califica como caché en la sección /cache de cualquier archivo de granja.
En las granjas de configuración de línea de base de AMS, encontrará nuestras órdenes de inclusión como se muestra a continuación:

/cache {
    /rules {
        $include "/etc/httpd/conf.dispatcher.d/cache/ams_author_cache.any"
    }

Al crear las reglas para lo que se debe almacenar en caché o no, consulte la documentación here

Creador de almacenamiento en caché

Hay muchas implementaciones que hemos visto en las que la gente no almacena en caché el contenido del autor.
Están perdiendo una gran actualización en rendimiento y capacidad de respuesta para sus autores.

Discutamos la estrategia tomada al configurar nuestra granja de autores para que almacene en caché correctamente.

Esta es una sección base de autor/caché de nuestro archivo de granja de autores:

/cache {
    /docroot "/mnt/var/www/author"
    /statfileslevel "2"
    /allowAuthorized "1"
    /rules {
        $include "/etc/httpd/conf.dispatcher.d/cache/ams_author_cache.any"
    }
    /invalidate {
        /0000 {
            /glob "*"
            /type "allow"
        }
    }
    /allowedClients {
        /0000 {
            /glob "*.*.*.*"
            /type "deny"
        }
        $include "/etc/httpd/conf.dispatcher.d/cache/ams_author_invalidate_allowed.any"
    }
}

Lo importante a tener en cuenta aquí es que la variable /docroot se establece en el directorio de caché del autor.

Nota:

Asegúrese de que DocumentRoot en el archivo .vhost del autor coincide con el parámetro /docroot de granjas.

La sentencia include de las reglas de caché incluye el archivo /etc/httpd/conf.dispatcher.d/cache/ams_author_cache.any que contiene estas reglas:

/0000 {
 /glob "*"
 /type "deny"
}
/0001 {
 /glob "/libs/*"
 /type "allow"
}
/0002 {
 /glob "/libs/*.html"
 /type "deny"
}
/0003 {
 /glob "/libs/granite/csrf/token.json"
 /type "deny"
}
/0004 {
 /glob "/apps/*"
 /type "allow"
}
/0005 {
 /glob "/apps/*.html"
 /type "deny"
}
/0006 {
 /glob "/libs/cq/core/content/welcome.*"
 /type "deny"
}

En un escenario de autor, el contenido cambia todo el tiempo y a propósito. Solo desea almacenar en caché los elementos que no van a cambiar con frecuencia.
Tenemos reglas para almacenar en caché /libs porque forman parte de la instalación de AEM de línea de base y cambiarían hasta que haya instalado un Service Pack, Cumulative Fix Pack, Upgrade o Hotfix. El almacenamiento en caché de estos elementos tiene mucho sentido y realmente beneficia a la experiencia de creación de los usuarios finales que utilizan el sitio.

Nota:

Tenga en cuenta que estas reglas también almacenan en caché /apps aquí es donde se encuentra el código de aplicación personalizado. Si está desarrollando su código en esta instancia, resultará muy confuso al guardar el archivo y no verá si se refleja en la interfaz de usuario debido a que proporciona una copia en caché. La intención aquí es que si implementa el código en AEM, también sería poco frecuente y parte de los pasos de implementación debería ser borrar la caché del autor. Una vez más, el beneficio es enorme, lo que hace que su código caché se ejecute más rápido para los usuarios finales.

ServeOnStale (también conocido como Serve on Stale / SOS)

Esta es una de esas gemas de una función de Dispatcher. Si el editor está en carga o no responde, normalmente arrojará un código de respuesta http 502 o 503. Si esto sucede y esta función está habilitada, se pedirá al despachante que siga sirviendo el contenido que aún esté en la caché como mejor esfuerzo, incluso si no es una copia nueva. Es mejor mostrar algo si lo tiene en lugar de mostrar un mensaje de error que no ofrece ninguna funcionalidad.

Nota:

Tenga en cuenta que si el procesador del editor tiene un tiempo de espera de socket o un mensaje de error 500, esta función no se déclencheur. Si AEM es inaccesible, esta función no hace nada.

Esta configuración se puede establecer en cualquier granja, pero aplicarla a los archivos de granja publicados solo tiene sentido. Este es un ejemplo de sintaxis de la función habilitada en un archivo de granja:

/cache {
    /serveStaleOnError "1"

Almacenamiento en caché de páginas con parámetros/argumentos de consulta

Nota:

Uno de los comportamientos normales del módulo Dispatcher es que si una solicitud tiene un parámetro de consulta en el URI (normalmente se muestra como /content/page.html?myquery=value) omitirá el almacenamiento en caché del archivo e irá directamente a la instancia de AEM. Está considerando esta solicitud como una página dinámica y no debería almacenarse en caché. Esto puede causar un efecto negativo en la eficiencia de la caché.

Si tiene páginas en AEM que toman argumentos de GET/parámetros de consulta en la línea de dirección que ayudan a que la página funcione pero no presentan HTML diferentes, son buenas candidatas para este elemento de configuración.

Puede indicar al despachante qué argumentos debe ignorar y seguir almacenando en caché la página.

Por ejemplo, alguien ha creado un mecanismo de referencia de vínculo profundo de medios sociales que utiliza la referencia de argumento en la URI para saber de dónde viene la persona.

Ejemplo de uso:

https://www.retail.com/home.html?reference=android

https://www.retail.com/home.html?reference=facebook

La página se puede almacenar al 100% en caché, pero no en caché porque los argumentos están presentes.
Para solucionarlo, agregamos la siguiente sección a nuestro archivo de configuración de granja:

/cache {
    /ignoreUrlParams {
        /0001 { /glob "*" /type "deny" }
        /0002 { /glob "reference" /type "allow" }
    }

Ahora, cuando el despachante ve la solicitud, ignora el hecho de que la solicitud tiene el parámetro de consulta de referencia y todavía almacena en caché la página.

Almacenamiento en caché de encabezados de respuesta

Es bastante obvio que Dispatcher almacena en caché páginas .html y clientlibs, pero ¿sabía que también podía almacenar en caché encabezados de respuesta particulares junto al contenido de un archivo con el mismo nombre pero con la extensión .h? Esto permite que la siguiente respuesta no solo sea el contenido, sino también los encabezados de respuesta que deberían ir con él desde la caché.

AEM manejar algo más que la codificación UTF-8.

A veces, los elementos tienen encabezados especiales que ayudan a controlar los detalles de codificación de TTL de la caché y las últimas marcas de tiempo modificadas.

Estos valores, cuando se almacenan en caché, se eliminan de forma predeterminada y el servidor web apache httpd hará su propio trabajo de procesamiento del recurso con sus métodos normales de gestión de archivos, que normalmente se limita a adivinar el tipo mime en función de las extensiones de archivo.

Si tiene la caché de Dispatcher del recurso y los encabezados deseados, puede exponer la experiencia adecuada y asegurarse de que todos los detalles lleguen al explorador de los clientes.

A continuación, se muestra un ejemplo de una granja con los encabezados que se van a almacenar en caché especificados:

/cache {
 /headers {
  "Cache-Control"
  "Content-Disposition"
  "Content-Type"
  "Expires"
  "Last-Modified"
  "X-Content-Type-Options"
 }
}

En el ejemplo, han configurado AEM para mostrar encabezados que la CDN busca para saber cuándo invalidar su caché. Esto significa que ahora AEM puede dictar correctamente qué archivos se invalidan en función de los encabezados.

Nota:

Tenga en cuenta que no puede utilizar expresiones regulares ni la coincidencia global. Es una lista literal de los encabezados que se van a almacenar en caché. Solo escriba una lista de los encabezados literales que desea que almacenen en caché.

Invalidar período de gracia automáticamente

En AEM sistemas que tienen mucha actividad de autores que realizan muchas activaciones de página, puede tener una condición de carrera en la que se producen invalidaciones repetidas. Las solicitudes de vaciado muy repetidas son innecesarias y puede incorporar cierta tolerancia para no repetir una descarga hasta que el período de gracia se haya borrado.

Ejemplo de cómo funciona esto:

Si tiene cinco solicitudes para invalidar /content/exampleco/es/, todas ocurren en un periodo de 3 segundos.

Con esta función desactivada, invalidaría el directorio de caché /content/exampleco/es/ 5 veces.

Con esta función activada y configurada en 5 segundos, invalidaría el directorio de caché /content/exampleco/en/once.

A continuación se muestra un ejemplo de sintaxis de esta función que se está configurando para un período de gracia de 5 segundos:

/cache {
    /gracePeriod "5"

Invalidación basada en TTL

Una característica más reciente del módulo de Dispatcher era Tiempo de vida (TTL) opciones de invalidación basadas en elementos en caché. Cuando un elemento se almacena en caché, busca la presencia de encabezados de control de caché y genera un archivo en el directorio de caché con el mismo nombre y un .ttl extensión.

Este es un ejemplo de la función que se está configurando en el archivo de configuración de la granja:

/cache {
    /enableTTL "1"

Nota:

Tenga en cuenta que aún AEM necesita configurarse para enviar encabezados TTL para que Dispatcher los respete. Alternar esta función solo permite que Dispatcher sepa cuándo eliminar los archivos que AEM han enviado encabezados de control de caché. Si AEM no comienza a enviar encabezados TTL, Dispatcher no hará nada especial aquí.

Reglas de filtro de caché

A continuación, se muestra un ejemplo de una configuración de línea de base para los elementos que se van a almacenar en caché en un publicador:

/cache{
    /0000 {
        /glob "*"
        /type "allow"
    }
    /0001 {
        /glob "/libs/granite/csrf/token.json"
        /type "deny"
    }

Queremos hacer que nuestro sitio publicado sea lo más ambicioso posible y almacenar en caché todo.

Si hay elementos que rompen la experiencia cuando se almacenan en caché, puede agregar reglas para eliminar la opción de almacenar ese elemento en caché. Como puede ver en el ejemplo anterior, los tokens csrf nunca deben almacenarse en caché y se han excluido. Encontrará más información sobre estas reglas here.

En esta página