Descripción general

Este artículo se centra en las últimas optimizaciones en Dispatcher AEM y cómo aprovecharlas al máximo.  Dispatcher AEM es un servidor proxy inverso de almacenamiento en caché diseñado para su uso con Adobe Experience Manager.  Puede instalarse y ejecutarse como un módulo dentro del software de servidor web existente.  En el momento de escribir este artículo, el módulo de Dispatcher es compatible con Apache HTTP Server, Microsoft IIS e iPlanet.

Funcionamiento de la caché de Dispatcher

En el nivel más básico, Dispatcher AEM es un proxy inverso que funciona realizando almacenamiento, vaciado e invalidación de la caché.  

Vea los enlaces relacionados para más detalles sobre Dispatcher:

  1. Funcionamiento e instalación de Dispatcher.
  2. Opciones de configuración disponibles en Dispatcher.
  3. Webinar sobre cómo funciona Dispatcher: note que alguna información en la presentación está basada en versiones antiguas de Dispatcher.
  4. Sesión de webinar sobre las funciones de Dispatcher, el uso de CDN y la seguridad.
  5. Sesión sobre las nuevas funciones de Dispatcher (posterior a la v4.1.9).

Optimización de la caché del Dispatcher

Aquí se encuentran algunas formas de optimizar la caché de Dispatcher:

  1. Almacenar en caché casi todo: esto significa almacenar en caché cualquier contenido que sea solicitado más de una vez por los usuarios.
  2. Almacenar en caché contenido personalizado durante diferentes períodos de tiempo: si su sitio tiene contenido personalizado, piense en utilizar Apache Sling Dynamic Includes en su aplicación AEM para aprovechar Ajax (llamadas asincrónicas JavaScript y XML a nivel de navegador), SSI (Server Side Includes a nivel de Servidor Web), y ESI (Edge-side Includes a nivel de CDN) para almacenar en caché diferentes partes de la página durante diferentes períodos de tiempo.
  3. Nunca borre la caché de Dispatcher en un Dispatcher en vivo: si Dispatcher está sirviendo contenido en vivo y usted borra la caché, verá una inundación masiva de solicitudes para volver a AEM.  Debido a esto, la caché de Dispatcher nunca debe borrarse en un Dispatcher en vivo.
  4. Cargar la caché: antes de borrar la caché de Dispatcher, retírelo de su equilibrador de carga, elimine la caché y, luego, ejecute una herramienta de rastreo web para almacenar los archivos en la caché de Dispatcher antes de añadirlo en el equilibrador de carga.
  5. Páginas de error de caché - Aproveche la directiva DispatcherPassError 1 (específica de Apache Web Server) para servir páginas de error como 404s desde la caché de Dispatcher.
  6. GZip comprime todos los tipos de archivos, excepto los que se han comprimido previamente. - En Apache Web Server, se puede usar mod_deflate, pero asegúrese de que el encabezado Vary: User-Agent no esté configurado.  En Microsoft IIS, utilice la Compresión Dinámica.
    Ejemplo de configuración de Apache (que especifica solo ciertos tipos de contenido para evitar tipos de archivos precomprimidos):
    AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript
  7. Habilitar /serveStaleOnError en la configuración de /caché: Se ocupa del archivo antiguo de caché cuando las instancias de AEM producen errores.
  8. Añadir /gracePeriod de la configuración de /cache: Define el número de segundos que un recurso obsoleto e invalidado de forma automática puede mandarse desde la caché después del último evento de publicación de contenido (“activación”).  Esto reduce el número de solicitudes que vuelven a las instancias de publicación durante una gran actividad de publicación de contenido, como una “Activación de árbol”.
  9. Añadir reglas a /ignoreUrlParams: ignora los parámetros de la cadena de consulta que no son requeridos o usados por la aplicación.  Esto permite el almacenamiento en caché de URL incluso cuando una cadena de consulta está presente.
  10. Almacenar en caché los encabezados de respuesta Cache-Control y Last-Modified: utilice la configuración /headers para almacenar en caché los encabezados de respuesta HTTP Cache-Control y Last-Modified (y/o el encabezado ETag si lo está enviando desde AEM).  Esto ayuda a simplificar y optimizar el almacenamiento en caché a nivel de CDN y de navegador.  El almacenamiento en caché de estos encabezados hace que solo AEM establezca los encabezados, no el servidor web en sí.  Tenga en cuenta que cuando haga esto, tendrá que empezar a enviar los encabezados desde su aplicación AEM.
  11. Almacene en caché el contenido el mayor tiempo posible y reduzca las solicitudes que se remontan a AEM - Optimice las solicitudes de vaciado permitiendo que todos los agentes de vaciado vuelvan a descargar.  Use /enableTTL y establezca el encabezado Cache-Control: max-age=... para almacenar archivos en caché el mayor tiempo posible.  Vea a continuación los detalles sobre este tema.

Uso de TTL

A partir de la versión de Dispatcher 4.2.3, /enableTTL 1 puede configurarse en el archivo de configuración .any.  Esta configuración hace que Dispatcher respete las caducidades de la caché establecidas en el encabezado de respuesta de HTTP Cache-Control.  En otras palabras, Dispatcher funcionará de manera similar a una CDN donde la forma primaria de invalidación de la caché ocurre cuando los archivos expiran.  Una vez implementado esto y comenzado a enviar Cache-Control: max-age=... para todas las respuestas de AEM, puede desactivar de forma segura sus agentes de vaciado de Dispatcher en las instancias de publicación.

Después de deshabilitar los agentes de vaciado en las instancias de publicación, es posible que desee vaciar la caché de Dispatcher.  En ese caso, puede utilizar ACS Commons - Dispatcher Flush UI.  Esta herramienta se instala en la instancia de autor.  Proporciona a los usuarios una interfaz de usuario en la que pueden realizar solicitudes de vaciado de caché manual.

I. Pasos para habilitar las invalidaciones de estilo TTL ("Time to Live" o expiración):

  1. Modificar el código fuente en la aplicación AEM para enviar el encabezado de Cache-Control y Última modificación para todas las peticiones en las que aún no esté configurado.
  2. Instale Dispatcher 4.2.3 o posterior.
  3. Establecer /enableTTL 1 en la configuración .any del sitio.
  4. Ajuste la configuración /encabezado para almacenar en caché los encabezados Cache-Control y Last-Modified.
  5. Reinicie el servidor web.

II. Desactivar los agentes de vaciado de Dispatcher en las instancias de publicación:

Dispatcher usará ahora el encabezado Cache-Control para controlar la invalidación de los archivos de caché.  Puesto que ese es el caso, ya no es necesario que Dispatcher se limpie de las instancias de publicación.

  1. Vaya a /etc/replication/agents.publish.html en cada instancia de publicación.
  2. Vaya a la configuración de cada agente de vaciado y deshabilite el agente.

III. Permitir que el Dispatcher manual limpie las solicitudes de la instancia de autor:

Ahora que los agentes de vaciado están deshabilitados, puede confiar completamente en el encabezado de Cache-Control para controlar cuándo se actualiza el contenido en Dispatcher.  Aún puede permitir que los usuarios emitan descargas manuales de la caché de Dispatcher.

  1. Instale ACS Commons - Interfaz de usuario de Dispatcher Flush en la instancia de autor.
  2. Configure los agentes de vaciado en la instancia de autor.
  3. En cada una de las configuraciones de agente, active la opción Activadores => Ignorar predeterminado. Esta opción hace que los agentes de vaciado ignoren cuando los usuarios hacen clic en Cancelar publicación o Desactivar en la interfaz de usuario de AEM.

Recuperación de vaciado de Dispatcher

Para optimizar las solicitudes de vaciado de Dispatcher, todos los agentes de vaciado deben tener habilitada una característica llamada descarga de recuperación.

Para habilitar la descarga de Dispatcher, haga lo siguiente:

  1. Vaya a http://aemhost:port/crx/packmgr/index.jsp e inicie sesión como administrador.
  2. Descargue el paquete desde aquí.
  3. Cargue e instale el paquete en el gestor de paquetes.
  4. Vaya a la configuración del agente de vaciado de su Dispatcher. Por ejemplo /etc/replication/agents.author/flush.html
  5. Haga clic en Editar.
  6. Ajuste lo siguiente
    • Tipo de serialización = Recoger la descarga de Dispatcher
    • Extendido => Método HTTP = POST
  7. Haga clic en Guardar

Tenga en cuenta que el paquete instalado anteriormente es solo un ejemplo básico.  Para personalizar y optimizar la descarga puede modificar la lista de URI que envía.  El código es libre y se puede encontrar aquí.  El código añade una lista de URI al cuerpo de la solicitud como parámetros que le indican a Dispatcher qué rutas recuperar.  Puede añadir más rutas según los requisitos de su aplicación para optimizar las capacidades de almacenamiento en caché de su sitio.

Una explicación más detallada de cómo vaciar las nuevas recuperaciones

Normalmente, una descarga de dispatcher trabaja borrando archivos:

  1. Archivo(s) .stat táctil(es)
  2. Borrar /content/foo.*
  3. Borrar /content/foo/_jcr_content

Debido al hecho de que los archivos se eliminan en el paso 2, la próxima vez que un usuario solicite un archivo como /content/foo.html o /content/foo.json, mientras que el archivo se está "recuperando", las solicitudes subsiguientes para el mismo archivo también se enviarán a las instancias de publicación hasta que el archivo se almacene en caché.  Para respuestas lentas o páginas de tráfico pesado como las páginas de inicio, esto puede causar una inundación del nivel de instancia de publicación.

Para resolver este problema, habilite una función de Dispatcher llamada recopilación.  Esta función le permite enviar una lista de URI que Dispatcher debe recuperar proactivamente y reemplazar en vez de borrar.

Vea 22:41-27:05 en este registro de presentación para una demostración de cómo funciona y cómo configurarlo.

Esta obra está autorizada con arreglo a la licencia de Reconocimiento-NoComercial-CompartirIgual 3.0 Unported de Creative Commons.  Los términos de Creative Commons no cubren las publicaciones en Twitter™ y Facebook.

Avisos legales   |   Política de privacidad en línea