Entender la caché

Este documento explicará cómo se realiza el almacenamiento en caché del Dispatcher y cómo se puede configurar.

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 Dispatcher, las solicitudes siguen las reglas configuradas para mantener una versión en caché local para responder a los elementos elegibles.

Nota:

Intencionalmente mantenemos la carga de trabajo publicada separada de la carga de trabajo de autor porque cuando Apache busca un archivo en el DocumentRoot no sabe de qué instancia de AEM procede.  Por lo tanto, incluso si tiene deshabilitada la caché en la granja de autores, si el DocumentRoot del autor es el mismo que el del editor, servirá los archivos de la caché cuando estén presentes.  Lo que significa que servirá archivos de autor desde la caché publicada y que será una experiencia de combinación realmente horrible para sus visitantes.

 

Mantener directorios DocumentRoot separados para diferentes contenidos publicados también es una mala idea.  Tendrá que crear varios elementos de la caché que no difieran entre sitios como clientlibs, así como tener que configurar un agente de replicación para cada DocumentRoot que configure.  Incrementar la cantidad de sobrecarga con cada activación de página.  Confíe en el espacio de área de nombres y sus rutas de caché completas y evite el uso de DocumentRoot's múltiples para los sitios publicados.

Archivos de configuración

El Dispatcher controla lo que califica como caché en la sección /cache { de cualquier archivo de granja.  En las granjas de configuración de la 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 sobre lo que se debe almacenar en caché o no, consulte la siguiente documentación

Autor del almacenamiento en caché

Hay muchas implementaciones que hemos visto en las que la gente no almacena en caché el contenido de autor.  Se están perdiendo una gran mejora en el rendimiento y la capacidad de respuesta a sus autores.

Hablemos de la estrategia tomada al configurar nuestra granja de autores para que guarde el caché correctamente.

Aquí hay una sección de autor base /cache { 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" 
    } 
}

Las cosas importantes a tener en cuenta aquí son que el /docroot está configurado para nosotros como el directorio de caché para el autor.

Nota:

Compruebe que su DocumentRoot en el archivo.vhost del autor coincide con el parámetro /docroot de granjas.

Las afirmaciones de órdenes de inclusión de las reglas de la caché incluyen 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 está cambiando todo el tiempo y a propósito.  Solo desea almacenar en caché elementos que no van a cambiar con frecuencia.  Tenemos reglas para almacenar en caché /libs porque son parte de la instalación básica de AEM y cambiarían hasta que usted haya instalado un Service Pack, Cumulative Fix Pack, Upgrade, o Hotfix.  Por lo tanto, el almacenamiento en caché de estos elementos tiene mucho sentido y realmente tiene grandes beneficios de la experiencia de autor 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 cuando guarde su archivo y no vea si se refleja en la interfaz de usuario debido a que muestra una copia en caché.  La intención aquí es que si usted hace un despliegue de su código en AEM, también sería poco frecuente y una parte de sus pasos de despliegue debería ser limpiar la caché de autor.  Una vez más, el beneficio es enorme, haciendo que su código caché se ejecute más rápido para los usuarios finales.

ServeOnStale (o lo que es lo mismo, Serve on Stale / SOS)

Esta es una de esas características de una vez que tiene el Dispatcher.  Si el editor está cargando o ha dejado de responder, normalmente lanzará un código de respuesta de 502 o 503 http.  Si eso sucede y esta función está activada, el Dispatcher aprenderá a mostrar cualquier contenido que todavía esté en la caché haciendo un esfuerzo, aunque no se trate de una copia nueva.  Es mejor mostrar algo si lo tienes en lugar de mostrar un mensaje de error que no ofrece ninguna funcionalidad.

Nota:

Tenga en cuenta que si el editor renderizador tiene un socket timeout o un mensaje de error 500, esta característica no se activará.  Si AEM es simplemente inaccesible, esta característica no hace nada.

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

/cache { 
    /serveStaleOnError "1"

Caché de páginas con parámetros de consulta / Argumentos

Nota:

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

Si tiene páginas en AEM que usan argumentos GET / parámetros de consulta en la línea de dirección que ayudan a la página a funcionar pero que no muestran diferentes html, son buenos candidatos para este elemento de configuración.

Puede indicar al Dispatcher qué argumentos debe ignorar y aún así almacenar en caché la página.

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

Ejemplo de uso:

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

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

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

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

Ahora, cuando el Dispatcher vea la petición, ignorará el hecho de que tiene el parámetro de consulta ?reference y todavía almacena en caché la página

Almacenamiento en caché de los encabezados de respuesta

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

AEM puede manejar algo más que la codificación UTF-8 (gran sonrisa)

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

Estos valores, cuando se almacenan en la caché, se quitan de forma predeterminada y el servidor web apache httpd hará su propio trabajo de procesar el activo con sus métodos normales de gestión de archivos, que normalmente se limita a adivinar el tipo mime basado en extensiones de archivo.

Si tiene el caché del Dispatcher, el activo y los encabezados deseados, puede exponer la experiencia adecuada y asegurar que todos los detalles lleguen al navegador del cliente.

Este es un ejemplo de una granja con los encabezados de caché especificados:

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

En el ejemplo se ha 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 basándose en los encabezados.

Nota:

Tenga en cuenta que no puede usar expresiones regulares o coincidencias de globos.  Es una lista literal de los encabezados que se deben almacenar en caché.  Solo tiene que hacer una lista de los encabezados literales que quiere almacenar en caché.

Autoinvalidar el período de gracia

En los sistemas AEM que tienen mucha actividad de autores que hacen muchas activaciones de páginas, puede tener una condición de carrera donde se produzcan invalidaciones repetidas.  Las solicitudes de descarga muy repetidas son innecesarias y puede incorporar alguna tolerancia para no repetir una descarga hasta que el período de gracia se haya despejado.

Ejemplo de cómo funciona esto:

Si tiene 5 peticiones para invalidar /content/exampleco/es/ todo sucede en un periodo de 3 segundos.

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

Con esta característica activada y configurada en 5 segundos, invalidaría una vez el directorio de caché /content/exampleco/es/

A continuación se muestra un ejemplo de sintaxis de esta característica 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 nueva del módulo del Dispatcher era las opciones de invalidación basadas en Time To Live (TTL) para los 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 una extensión .ttl

Aquí hay un ejemplo de la característica que se está configurando en el archivo de configuración de la granja:

/cache { 
    /enableTTL "1"
Nota:

Tenga en cuenta que AEM todavía necesita ser configurado para enviar encabezados TTL para que Dispatcher los reconozca.  Conmutar esta función solo permite al Dispatcher saber cuándo eliminar los archivos para los que AEM ha enviado las cabeceras de control de caché.  Si el AEM no comienza a enviar encabezados TTL, el Dispatcher no hará nada especial aquí.

Reglas del filtro de caché

A continuación se muestra un ejemplo de una configuración de línea de base para los elementos que se almacenan en caché en un editor:

/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 que consiga almacenar todo en caché.

Si hay elementos que rompen la experiencia cuando se almacenan en caché, puede añadir reglas para eliminar la opción de almacenar ese elemento.  Como puede ver en el ejemplo anterior, los tokens csrf no deben ser nunca almacenados en caché y han sido excluidos.  Encuentre aquí más información sobre estas reglas.