Introducción

El tráfico pasa a través de la CDN a una capa de servidor web apache, que admite módulos, incluido el despachante. Para aumentar el rendimiento, el despachante se utiliza principalmente como caché para limitar el procesamiento en los nodos de publicación.
Se pueden aplicar reglas a la configuración del despachante para modificar cualquier configuración de caducidad de caché predeterminada, lo que resulta en almacenamiento en caché en CDN. Tenga en cuenta que el despachante también respeta los encabezados de caducidad de caché resultantes si enableTTL está habilitado en la configuración del despachante, lo que implica que actualizará contenido específico incluso fuera del contenido que se está republicando.

En esta página también se describe cómo se invalida la caché del despachante, así como cómo funciona la caché a nivel del explorador con respecto a las bibliotecas del lado del cliente.

Almacenamiento en caché

HTML/Texto

de forma predeterminada, el explorador almacena en caché durante cinco minutos, según el encabezado de control de caché emitido por la capa apache. La CDN también respeta este valor.
se puede anular para todo el contenido HTML/Texto definiendo la variable EXPIRATION_TIME en global.vars mediante el uso de la AEM como herramienta de Dispatcher de SDK para Cloud Service.
se puede anular en un nivel más fino mediante las siguientes directivas apache mod_headers:
```
<LocationMatch "\.(html)$">
     Header set Cache-Control "max-age=200"
     Header set Age 0
</LocationMatch>
```
Tenga cuidado al configurar encabezados de control de caché globales o aquéllos que coinciden con un regex amplio, de modo que no se apliquen al contenido que pueda tener la intención de mantener como privado. Considere la posibilidad de utilizar varias directivas para garantizar que las reglas se apliquen de manera precisa. Dicho esto, AEM como Cloud Service quitará el encabezado de la memoria caché si detecta que se ha aplicado a lo que detecta que el despachante no puede almacenar en caché, tal como se describe en la documentación del despachante. Para obligar a AEM a aplicar siempre almacenamiento en caché, se puede agregar la opción "siempre" de la siguiente manera:
```
<LocationMatch "\.(html)$">
     Header always set Cache-Control "max-age=200"
     Header set Age 0
</LocationMatch>
```
Debe asegurarse de que un archivo de src/conf.dispatcher.d/cache tiene la siguiente regla (que está en la configuración predeterminada):
```
/0000
{ /glob "*" /type "allow" }
```
Para evitar que se almacene en caché contenido específico, establezca el encabezado Cache-Control en private. Por ejemplo, lo siguiente impediría que el contenido HTML de un directorio llamado myfolder se almacene en caché:
```
   <LocationMatch "/myfolder/.*\.(html)$">.  // replace with the right regex
   Header set Cache-Control “private”
  </LocationMatch>
```
NOTA

Los demás métodos, incluido el proyecto dispatcher-ttl AEM ACS Commons, no anularán correctamente los valores.

Bibliotecas de cliente (js,css)

al utilizar AEM marco de biblioteca del cliente, el código JavaScript y CSS se genera de forma que los navegadores pueden almacenarlo en caché indefinidamente, ya que cualquier cambio se manifiesta como nuevos archivos con una ruta única. En otras palabras, el HTML que hace referencia a las bibliotecas de cliente se producirá según sea necesario para que los clientes puedan experimentar contenido nuevo a medida que se publica. El control de caché se establece en "inmutable" o en 30 días para los exploradores más antiguos que no respetan el valor "inmutable".
consulte la sección Bibliotecas del lado del cliente y coherencia de la versión para obtener más detalles.

Imágenes y cualquier contenido lo suficientemente grande almacenado en el almacenamiento de blob

de forma predeterminada, no en caché
puede establecerse en un nivel más fino mediante las siguientes directivas apache mod_headers:
```
   <LocationMatch "^\.*.(jpeg|jpg)$">
     Header set Cache-Control "max-age=222"
     Header set Age 0
   </LocationMatch>
```
Consulte la discusión en la sección html/text de arriba para tener cuidado de no almacenar demasiado en caché y también para forzar a AEM a aplicar siempre la caché con la opción "siempre".

Es necesario asegurarse de que un archivo en src/conf.dispatcher.d/caché tiene la siguiente regla (que se encuentra en la configuración predeterminada):
```
/0000
{ /glob "*" /type "allow" }
```
Asegúrese de que los recursos destinados a ser guardados en privado en lugar de en caché no forman parte de los filtros de directiva LocationMatch.

NOTA

Los demás métodos, incluido el proyecto dispatcher-ttl AEM ACS Commons, no anularán correctamente los valores.

Otros tipos de archivos de contenido en el almacén de nodos

sin caché predeterminada
el valor predeterminado no se puede establecer con la variable EXPIRATION_TIME utilizada para los tipos de archivo html/text
la caducidad de la caché se puede establecer con la misma estrategia LocationMatch descrita en la sección html/text especificando el regex adecuado

Invalidación de caché de despachante

En general, no será necesario invalidar la caché del despachante. En su lugar, debe confiar en que el despachante actualice su caché cuando se vuelva a publicar el contenido y en que la CDN respete los encabezados de caducidad de la caché.

Invalidación de caché de despachante durante la Activación/desactivación

Al igual que las versiones anteriores de AEM, las páginas de publicación o cancelación de publicación borrarán el contenido de la caché del despachante. Si se sospecha un problema de almacenamiento en caché, los clientes deben volver a publicar las páginas en cuestión.

Cuando la instancia de publicación recibe una nueva versión de una página o recurso del autor, utiliza el agente de vaciado para invalidar las rutas adecuadas en su distribuidor. La ruta de acceso actualizada se elimina de la memoria caché del despachante, junto con sus elementos principales, hasta un nivel (puede configurarla con el nivel de archivo de estado.

Invalidez de caché de despachante explícita

En general, no será necesario invalidar manualmente el contenido en el despachante, pero es posible si es necesario, tal como se describe a continuación.

Antes de AEM como Cloud Service, había dos maneras de invalidar la caché del despachante.

Invocar el agente de replicación, especificando el agente de vaciado del despachante de publicación
Llamando directamente a la API invalidate.cache (por ejemplo, POST /dispatcher/invalidate.cache)

Ya no se admitirá el método de API invalidate.cache del despachante, ya que solo se dirige a un nodo de despachante específico. AEM como Cloud Service funciona en el nivel de servicio, no en el nivel de nodo individual, por lo que las instrucciones de invalidación de la página Invalidación de páginas en caché de AEM ya no son válidas para AEM como Cloud Service.
En su lugar, debe utilizarse el agente de vaciado de replicación. Esto se puede hacer con la API de replicación. La documentación de la API de replicación está disponible aquí y para ver un ejemplo de vaciado de la caché, consulte la página de ejemplo de la API específicamente el ejemplo CustomStep que emite una acción de replicación de tipo ACTIVATE a todos los agentes disponibles. El extremo del agente de vaciado no se puede configurar pero está preconfigurado para que apunte al despachante, junto con el servicio de publicación que ejecuta el agente de vaciado. Normalmente, el agente de vaciado puede activarse mediante eventos o flujos de trabajo OSGi.

El diagrama que se presenta a continuación ilustra esto.

Si existe la preocupación de que la memoria caché del despachante no esté borrando, póngase en contacto con Asistencia al cliente quién puede vaciar la memoria caché del despachante si es necesario.

La CDN gestionada por el Adobe respeta los TTL y, por lo tanto, no es necesario vaciarla. Si se sospecha un problema, póngase en contacto con el soporte técnico para que pueda vaciar una caché de CDN administrada por Adobe según sea necesario.

Bibliotecas del lado del cliente y coherencia de la versión

Las páginas están compuestas de HTML, JavaScript, CSS e imágenes. Se recomienda a los clientes aprovechar el marco de bibliotecas del lado del cliente (clientlibs) para importar recursos de JavaScript y CSS en páginas HTML, teniendo en cuenta las dependencias entre bibliotecas de JS.

El módulo clientlibs proporciona administración automática de versiones, lo que significa que los desarrolladores pueden registrar cambios en las bibliotecas JS en el control de código fuente y la última versión estará disponible cuando un cliente implemente su versión. Sin esto, los desarrolladores necesitarían cambiar manualmente HTML con referencias a la nueva versión de la biblioteca, lo que resulta especialmente oneroso si muchas plantillas HTML comparten la misma biblioteca.

Cuando las nuevas versiones de las bibliotecas se publican en producción, las páginas HTML de referencia se actualizan con nuevos vínculos a esas versiones de biblioteca actualizadas. Una vez que la caché del explorador ha caducado para una página HTML determinada, no hay problema de que las bibliotecas antiguas se carguen desde la caché del explorador, ya que la página actualizada (desde AEM) ahora está garantizada para hacer referencia a las nuevas versiones de las bibliotecas. En otras palabras, una página HTML actualizada incluirá todas las versiones de biblioteca más recientes.

El mecanismo para esto es un hash serializado, que se anexa al vínculo de la biblioteca del cliente, lo que garantiza una dirección URL única y con versiones para que el explorador almacene en caché CSS/JS. El hash serializado solo se actualiza cuando cambia el contenido de la biblioteca del cliente. Esto significa que si se producen actualizaciones no relacionadas (es decir, no se producen cambios en los css/js subyacentes de la biblioteca del cliente) incluso con una nueva implementación, la referencia permanece igual, lo que garantiza una menor interrupción en la caché del explorador.

Activación de versiones Longcache de bibliotecas del lado del cliente: AEM como un inicio rápido del SDK del Cloud Service

La clientlib predeterminada incluye en una página HTML un aspecto similar al siguiente ejemplo:

<link rel="stylesheet" href="/etc.clientlibs/wkndapp/clientlibs/clientlib-base.css" type="text/css">

Cuando está habilitado el control de versiones clientlib estricto, se agrega una clave hash a largo plazo como selector a la biblioteca del cliente. Como resultado, la referencia clientlib tiene este aspecto:

<link rel="stylesheet" href="/etc.clientlibs/wkndapp/clientlibs/clientlib-base.lc-7c8c5d228445ff48ab49a8e3c865c562-lc.css" type="text/css">

El control de versiones de clientlib estricto está habilitado de forma predeterminada en todos los AEM como entornos de Cloud Service.

Para habilitar el control de versiones estrictas de clientlib en el SDK local Quickstart, realice las siguientes acciones:

Vaya al Administrador de configuración de OSGi <host>/system/console/configMgr
Busque el Administrador de biblioteca HTML de OSGi para Adobe Granite:
- Marque la casilla de verificación para habilitar el control estricto de versiones
- En el campo rotulado Clave de caché del lado del cliente a largo plazo, introduzca el valor de /.*;hash
Guarde los cambios. Tenga en cuenta que no es necesario guardar esta configuración en el control de código fuente, ya que AEM como Cloud Service habilitará automáticamente esta configuración en entornos de desarrollo, etapa y producción.
Cada vez que se cambia el contenido de la biblioteca del cliente, se genera una nueva clave hash y se actualiza la referencia HTML.