Capítulo 1: Conceptos, patrones y antipatrones de Dispatcher

URL de sufijos en conflicto

Imagine que tiene dos direcciones URL válidas

http://domain.com/home.html

y

http://domain.com/home.html/suffix.html

AEM Son absolutamente válidos en la práctica de la. No vería ningún problema en su equipo de desarrollo local (sin un Dispatcher). Lo más probable es que tampoco encuentre ningún problema en las pruebas de carga o UAT. El problema que enfrentamos es tan sutil que se desliza por la mayoría de las pruebas. Esto le golpeará fuertemente cuando esté en las horas de mayor actividad y tenga un tiempo limitado para solucionarlo, probablemente no tenga acceso al servidor ni recursos para solucionarlo. Hemos estado allí…

Entonces… ¿cuál es el problema?

home.html en un sistema de archivos puede ser un archivo o una carpeta. AEM No ambos al mismo tiempo que en el caso de la.

Si solicita home.html primero, se creará como un archivo.

Las solicitudes posteriores a home.html/suffix.html devuelven resultados válidos, pero como el archivo home.html "bloquea" la posición en el sistema de archivos, home.html no se puede crear por segunda vez como carpeta y, por lo tanto, home.html/suffix.html no se almacena en caché.

Posición de bloqueo de archivos en el sistema de archivos que impide que se almacenen en caché los subrecursos

Si lo hace al revés, primero debe solicitar home.html/suffix.html y después suffix.html se almacena en la caché en una carpeta /home.html al principio. Sin embargo, esta carpeta se elimina y se reemplaza por un archivo home.html cuando posteriormente se solicita home.html como recurso.

Eliminando una estructura de ruta de acceso cuando se busca un recurso principal

Por lo tanto, el resultado de lo que se almacena en caché es completamente aleatorio y depende del orden de las solicitudes entrantes. Lo que hace que las cosas sean aún más complicadas es el hecho de que normalmente tiene más de un distribuidor. Además, el rendimiento, la tasa de aciertos de caché y el comportamiento pueden variar de un Dispatcher a otro. Si desea saber por qué su sitio web no responde, debe asegurarse de que está viendo el Dispatcher correcto con el desafortunado orden de almacenamiento en caché. Si estás buscando en el Dispatcher que - por suerte - tenía un patrón de solicitud más favorable, te perderás en tratar de encontrar el problema.

Implementación de la invalidación automática: el archivo .stat

Ahora, si tiene un sitio grande con miles de páginas, tardaría bastante tiempo en recorrer todas las páginas y eliminarlas físicamente. Durante ese periodo, Dispatcher podría ofrecer contenido obsoleto de forma involuntaria. Peor aún: pueden producirse algunos conflictos al acceder a los archivos de caché, puede que se solicite una página mientras se elimina o que se vuelva a eliminar una página debido a una segunda invalidación que se produjo después de una activación posterior inmediata. Piensen en el desastre que sería. Por suerte, esto no es lo que pasa. El Dispatcher utiliza un truco inteligente para evitarlo: en lugar de eliminar cientos y miles de archivos, coloca un archivo simple y vacío en la raíz del sistema de archivos cuando se publica un archivo y, por lo tanto, todos los archivos dependientes se consideran no válidos. Este archivo se denomina "archivo de estado". El archivo de estado es un archivo vacío: lo que importa sobre el archivo de estado es su fecha de creación.

Todos los archivos de Dispatcher que tienen una fecha de creación anterior al archivo de estado, se han procesado antes de la última activación (e invalidación) y, por lo tanto, se consideran "no válidos". Todavía están físicamente presentes en el sistema de archivos, pero Dispatcher los ignora. Son "anticuados". Cada vez que se realiza una solicitud a un recurso obsoleto, Dispatcher AEM solicita al sistema de que vuelva a procesar la página. Esa página recién procesada se almacena en el sistema de archivos, ahora con una nueva fecha de creación y se actualiza de nuevo.

La fecha de creación del archivo .stat define qué contenido está obsoleto y cuál es nuevo

¿Puede preguntar por qué se llama ".stat"? ¿Y no quizás ".invalidada"? Bueno, puede imaginar que tener ese archivo en su sistema de archivos ayuda a Dispatcher a determinar qué recursos se podrían servir estáticamente, al igual que desde un servidor web estático. Estos archivos ya no necesitan procesarse de forma dinámica.

La verdadera naturaleza del nombre, sin embargo, es menos metafórica. Se deriva de la llamada al sistema Unix stat(), que devuelve la hora de modificación de un archivo (entre otras propiedades).

Combinación de validación simple y automática

Pero espera… antes dijimos, que los recursos individuales se borran físicamente. Ahora decimos, que un archivo de estado más reciente virtualmente los haría inválidos a los ojos de la Dispatcher. ¿Por qué entonces la eliminación física, primero?

La respuesta es simple. Normalmente se utilizan ambas estrategias en paralelo, pero para distintos tipos de recursos. Los recursos binarios, como las imágenes, son independientes. No están conectados a otros recursos en el sentido de que necesitan que se represente su información.

Las páginas HTML, por otro lado, son altamente interdependientes. Por lo tanto, debe aplicar la invalidación automática en esos casos. Esta es la configuración predeterminada de Dispatcher. Todos los archivos que pertenecen a un recurso invalidado se eliminan físicamente. Además, los archivos que terminan con ".html" se invalidan automáticamente.

Dispatcher decide la extensión del archivo, aplique o no el esquema de invalidación automática.

Los finales de archivo para la invalidación automática se pueden configurar. En teoría, puede incluir todas las extensiones para la invalidación automática. Pero tenga en cuenta que esto tiene un precio muy alto. No verá que los recursos antiguos se entreguen de forma involuntaria, pero el rendimiento de la entrega se degrada considerablemente debido a la invalidación excesiva.

Imagine, por ejemplo, que implementa un esquema en el que los archivos PNG y los JPG de la se representan dinámicamente y dependen de otros recursos para hacerlo. Es posible que desee cambiar la escala de las imágenes de alta resolución a una resolución más pequeña compatible con la Web. Mientras estás en esto también cambia la tasa de compresión. La resolución y la tasa de compresión de este ejemplo no son constantes fijas, sino parámetros configurables en el componente que utiliza la imagen. Ahora, si se cambia este parámetro, es necesario invalidar las imágenes.

No hay problema: acabamos de aprender que podemos añadir imágenes a la invalidación automática y que siempre tenemos imágenes recién procesadas cada vez que cambia algo.

Tirando al bebé con el agua de baño

Así es, y ese es un gran problema. Vuelva a leer el último párrafo. "…imágenes recién procesadas cada vez que cambia algo." Como ya sabe, un buen sitio web cambia constantemente; se añade nuevo contenido aquí, se corrige un error tipográfico allí, y se modifica un teaser en otro lugar. Esto significa que todas las imágenes se invalidan constantemente y deben volver a procesarse. No subestimes eso. El procesamiento y la transferencia dinámicos de datos de imagen funcionan en milisegundos en la máquina de desarrollo local. El entorno de producción debe hacerlo cien veces más a menudo, por segundo.

Y seamos claros aquí, sus jpgs necesitan ser renderizados, cuando cambia una página html y viceversa. Solo hay un "bloque" de archivos que se va a invalidar automáticamente. Se limpia como un todo. Sin ningún medio de descomponerse en estructuras más detalladas.

Hay una buena razón por la que la invalidación automática se mantiene en ".html" de forma predeterminada. El objetivo es mantener ese cubo lo más pequeño posible. No tire al bebé con el agua del baño simplemente invalidando todo, solo para estar en el lado seguro.

Los recursos independientes deben servirse en la ruta de ese recurso. Eso ayuda mucho a la invalidación. Para ser más sencillos, no cree esquemas de asignación como "resource /a/b/c" se proporciona desde "/x/y/z". Haga que los componentes funcionen con la configuración de invalidación automática predeterminada de Dispatcher. No intente reparar un componente mal diseñado con invalidación excesiva en Dispatcher.

Creación de componentes teniendo en cuenta Dispatcher

Aplicación de la mecánica de Dispatcher en un ejemplo real

En el último capítulo explicamos cómo funciona la mecánica básica de Dispatcher, cómo funciona en general y cuáles son las limitaciones.

Ahora queremos aplicar estas mecánicas a un tipo de componentes que muy probablemente encontrará en los requisitos de su proyecto. Elegimos el componente deliberadamente para demostrar problemas que también enfrentará tarde o temprano. No teman - no todos los componentes necesitan esa cantidad de consideración que vamos a presentar. Pero si ve la necesidad de crear un componente de este tipo, es muy consciente de las consecuencias y sabe cómo manejarlas.

Patrón del componente de bobinado (Anti)

El componente Imagen interactiva

Ilustremos un patrón común (o antipatrón) de un componente con binarios interconectados. Crearemos un componente "respi": para "imagen adaptable". Este componente debe poder adaptar la imagen visualizada al dispositivo en el que se muestra. En escritorios y tabletas muestra la resolución completa de la imagen, en teléfonos una versión más pequeña con un recorte estrecho - o tal vez incluso un motivo completamente diferente (esto se llama "dirección de arte" en el mundo interactivo).

AEM Los recursos se cargan en el área DAM de y solo se hace referencia a ellos en el componente de imagen adaptable.

El componente de respi se encarga de procesar el marcado y de entregar los datos de imagen binarios.

AEM La forma en que lo implementamos aquí es un patrón común que hemos visto en muchos proyectos e incluso uno de los componentes principales de la se basa en ese patrón. Por lo tanto, es muy probable que usted como desarrollador pueda adaptar ese patrón. Tiene sus puntos dulces en términos de encapsulación, pero requiere mucho esfuerzo para prepararlo para Dispatcher. Discutiremos varias opciones sobre cómo mitigar el problema más adelante.

Llamamos al patrón usado aquí "Patrón de cola", porque el problema se remonta a los primeros días del Comunicado 3, donde había un método "bobina" que se podía llamar en un recurso para transmitir sus datos binarios sin procesar en la respuesta.

El término original "puesta en cola" hace referencia a periféricos compartidos sin conexión lentos, como impresoras, por lo que no se aplica aquí correctamente. Pero nos gusta el término de todos modos, porque rara vez en el mundo en línea, por lo tanto, distinguible. Y cada patrón debería tener un nombre distinguible de todos modos, ¿verdad? Depende de ti decidir si esto es un patrón o un anti-patrón.

Donde brilla el patrón de cola de impresión

Hay una excepción natural, donde este patrón incluso en su forma simple es útil: Si el binario se almacena en el propio componente, y no en el DAM. Sin embargo, esto solo es útil para imágenes utilizadas una vez en el sitio web y no almacenar recursos en el DAM significa que le cuesta mucho administrar sus recursos. Imagine que se agota su licencia de uso de un recurso concreto. ¿Cómo puede saber qué componentes ha utilizado el recurso?

¿Lo ves? La "M" en DAM significa "Administración", como en la Administración de activos digitales. No quiere revelar esa característica de forma gratuita.

Conclusión

AEM Desde el punto de vista de un desarrollador de, el patrón parecía súper elegante. Pero con la Dispatcher en la ecuación, podrían estar de acuerdo, en que el enfoque ingenuo podría no ser suficiente.

Por ahora, dejamos que usted decida si esto es un patrón o un anti-patrón. ¿Y tal vez ya tiene algunas buenas ideas en mente sobre cómo mitigar los problemas explicados anteriormente? Bien. Entonces debería estar ansioso por ver cómo otros proyectos han resuelto estos problemas.

Solución de problemas comunes de Dispatcher

Información general

Hablemos de cómo se podría haber implementado un poco más compatible con la caché. Hay varias opciones. A veces no se puede elegir la mejor solución. Tal vez entra en un proyecto que ya está en ejecución y tiene un presupuesto limitado para solucionar el "problema de caché" que tiene a mano y no lo suficiente para hacer una refactorización completa. O se enfrenta a un problema, que es más complejo que el componente de imagen de ejemplo.

Describiremos los principios y las advertencias en las siguientes secciones.

De nuevo, esto se basa en la experiencia de la vida real. Ya hemos visto todos esos patrones en la naturaleza, así que no es un ejercicio académico. Es por eso que les mostramos algunos antipatrones, así que tienen la oportunidad de aprender de los errores que otros ya han cometido.

Huella digital de URL

La huella digital de una URL parece un asesino en caché. Pero no lo es. No es un número aleatorio, sino un valor que caracteriza el contenido del recurso. Puede ser un hash del contenido del recurso o, más simple aún, una marca de tiempo cuando el recurso se cargó, editó o actualizó.

Una marca de tiempo Unix es suficientemente buena para una implementación en el mundo real. Para mejorar la legibilidad, se utiliza un formato más legible en este tutorial: 2018 31.12 23:59 or fp-2018-31-12-23-59.

La huella digital no debe utilizarse como parámetro de consulta, como las direcciones URL con parámetros de consulta no se puede almacenar en caché. Puede utilizar un selector o el sufijo para la huella digital.

Supongamos que el archivo /content/dam/flower.jpg tiene una fecha jcr:lastModified del 31 de diciembre de 2018 a las 23:59. La dirección URL con la huella digital es /content/home/jcr:content/par/respi.fp-2018-31-12-23-59.jpg.

Esta dirección URL permanece estable, siempre y cuando no se cambie el archivo de recursos al que se hace referencia (flower.jpg). Por lo tanto, se puede almacenar en caché durante un tiempo indefinido y no es un asesino en caché.

Tenga en cuenta que esta URL debe crearla y servirla el componente de imagen adaptable. AEM No se trata de una funcionalidad predeterminada de la aplicación de la aplicación de la aplicación de la aplicación de la aplicación de la.

Ese es el concepto básico. Sin embargo, hay algunos detalles que podrían pasarse por alto fácilmente.

En nuestro ejemplo, el componente se procesó y se almacenó en caché a las 23:59. Ahora la imagen ha cambiado, digamos a las 00:00. El componente generaría una nueva dirección URL con huellas digitales en su marcado.

Puede que pienses que debería… pero no es así. Como solo se ha cambiado el binario de la imagen y no se ha tocado la página incluida, no es necesario volver a procesar el marcado del HTML. Por lo tanto, el Dispatcher sirve la página con la huella digital antigua, y por lo tanto la versión antigua de la imagen.

El componente de imagen es más reciente que la imagen a la que se hace referencia, no se procesó ninguna huella digital nueva.

Ahora, si vuelve a activar la página de inicio (o cualquier otra página de ese sitio) en la que se actualiza el archivo de estado, Dispatcher considera que el archivo home.html está obsoleto y lo vuelve a procesar con una nueva huella digital en el componente de imagen.

Pero no activamos la página principal, ¿verdad? ¿Y por qué deberíamos activar una página que no tocamos de todos modos? Además, tal vez no tengamos suficientes derechos para activar páginas o el flujo de trabajo de aprobación es tan largo y lleva tanto tiempo que simplemente no podemos hacerlo con tan poco tiempo de antelación. Entonces, ¿qué hacer?

Un descanso corto

Vaya, hay muchos detalles que hay que tener en cuenta, ¿no? Y se niega a ser entendido, probado y depurado fácilmente. Y todo por una solución aparentemente elegante. AEM Hay que reconocer que es elegante, pero solo desde una perspectiva de solo un. Junto con el Dispatcher se vuelve desagradable.

Y aún así - no resuelve una advertencia básica, si una imagen se utiliza varias veces en diferentes páginas, se almacenan en caché en esas páginas. No hay mucha sinergia de almacenamiento en caché allí.

En general, la huella digital de URL es una buena herramienta para tener en su kit de herramientas, pero debe aplicarla con cuidado, ya que puede causar nuevos problemas al resolver solo unos pocos existentes.

Así que… ese fue un capítulo largo. Pero hemos visto este patrón tan a menudo, que sentimos que es necesario darle toda la imagen con todos los pros y los contras. Las huellas digitales de URL resuelven algunos de los problemas inherentes al patrón de cola de impresión, pero el esfuerzo por implementar es bastante alto y también necesita considerar otras soluciones (más fáciles). Nuestro consejo es comprobar siempre si puede basar sus URL en las rutas de recursos servidas y no tener un componente intermedio. Llegaremos a esto en el siguiente capítulo.

Resolución de dependencias de tiempo de ejecución

La resolución de dependencias en tiempo de ejecución es un concepto que hemos estado considerando en un proyecto. Pero pensándolo bien, se hizo bastante complejo y decidimos no implementarlo.

Esta es la idea básica:

Dispatcher no conoce las dependencias de los recursos. Es sólo un montón de archivos individuales con poca semántica.

AEM También sabe poco acerca de las dependencias. Carece de una semántica adecuada o de un "rastreador de dependencias".

AEM es consciente de algunas de las referencias. Utiliza este conocimiento para advertirle cuando intenta eliminar o mover una página o recurso al que se hace referencia. Lo hace consultando la búsqueda interna al eliminar un recurso. Las referencias de contenido tienen una forma muy particular. Son expresiones de ruta que comienzan por "/content". Por lo tanto, se pueden indexar fácilmente con texto completo y consultarlas cuando sea necesario.

En nuestro caso, necesitaríamos un agente de replicación personalizado en el sistema de Publish, que déclencheur una búsqueda de una ruta específica cuando esa ruta haya cambiado.

Digamos que…

/content/dam/flower.jpg

Ha cambiado en Publish. El agente activaría una búsqueda de "/content/dam/flower.jpg" y encontraría todas las páginas que hacen referencia a esas imágenes.

Entonces podría enviar una serie de solicitudes de invalidación a Dispatcher. Uno por cada página que contenga el recurso.

En teoría, eso debería funcionar. Pero solo para dependencias de primer nivel. No le gustaría aplicar ese esquema para dependencias de varios niveles, por ejemplo, cuando utiliza la imagen en un fragmento de experiencia que se utiliza en una página. En realidad, creemos que ese enfoque es demasiado complejo -y podría haber problemas en tiempo de ejecución. Y, por lo general, el mejor consejo es no hacer computación costosa en los controladores de eventos. Y sobre todo la búsqueda puede llegar a ser bastante caro.

Conclusión

Esperamos haber analizado el patrón de cola de impresión lo suficientemente a fondo como para ayudarle a decidir cuándo utilizarlo y no en su implementación.

Evitar problemas de Dispatcher

URL basadas en recursos

Una forma mucho más elegante de resolver el problema de la dependencia es no tener dependencias en absoluto. Evite las dependencias artificiales que se producen al utilizar un recurso para simplemente representar a otro, como hicimos en el último ejemplo. Intente ver los recursos como entidades "solitarias" con la mayor frecuencia posible.

Nuestro ejemplo se resuelve fácilmente:

Poner en cola la imagen con un servlet enlazado a la imagen, no al componente.

Utilizamos los recursos originales de las rutas de recursos para procesar los datos. AEM Si necesitamos procesar la imagen original tal cual, solo podemos utilizar el procesador predeterminado para los recursos de la aplicación de procesamiento de datos de manera predeterminada de los recursos.

Si necesitamos realizar algún procesamiento especial para un componente específico, registraríamos un servlet dedicado en esa ruta y un selector para realizar la transformación en nombre del componente. Lo hicimos aquí ejemplar con el ".respi". selector. Es aconsejable realizar un seguimiento de los nombres de los selectores que se usan en el espacio de URL global (como /content/dam) y tener una buena convención de nombres para evitar conflictos de nombres.

Por cierto: no vemos ningún problema con la coherencia del código. El servlet se puede definir en el mismo paquete Java que el modelo de componentes sling.

Incluso podemos usar selectores adicionales en el espacio global como,

/content/dam/flower.respi.thumbnail.jpg

Tranquilo, ¿verdad? Entonces, ¿por qué la gente viene con patrones complicados como el Spooler?

Bueno, podríamos resolver el problema evitando la referencia de contenido interna porque el componente externo agregaba poco valor o información a la representación del recurso interno, que podría codificarse fácilmente en un conjunto de selectores estáticos que controlan la representación de un recurso solitario.

Sin embargo, hay una clase de casos que no se pueden resolver fácilmente con una dirección URL basada en recursos. Este tipo de casos se denomina "Parámetro de inyección de componentes" y se analizan en el capítulo siguiente.

Parámetro de inyección de componentes

Información general

El Cola del último capítulo era solo un envoltorio delgado alrededor de un recurso. Causó más problemas que ayudar a resolver el problema.

Podríamos sustituir fácilmente ese envoltorio utilizando un selector simple y añadir un servlet adecuado para servir esas solicitudes.

Pero ¿qué sucede si el componente "respi" es más que solo un proxy. ¿Qué sucede si el componente contribuye de forma genuina a la renderización del componente?

Vamos a introducir una pequeña extensión de nuestro componente "respi", que es un poco un cambio de juego. Una vez más, primero presentaremos algunas soluciones ingenuas para abordar los nuevos desafíos y mostrar dónde se quedan cortas.

El Componente Respi2

El componente respi2 es un componente que muestra una imagen adaptable, como lo es el componente respi. Pero tiene un ligero complemento,

estructura de CRX: el componente respi2 agrega una propiedad de calidad a la entrega

Las imágenes son JPEG y se pueden comprimir. Cuando comprime una imagen JPEG, intercambia la calidad por el tamaño del archivo. La compresión se define como un parámetro numérico de "calidad" que varía de "1" a "100". "1" significa "calidad pequeña pero mala", "100" significa "excelente calidad pero archivos grandes". Entonces, ¿cuál es el valor perfecto?

Como en todas las cosas de TI, la respuesta es: "Depende".

Aquí depende del motivo. Los motivos con bordes de alto contraste como los motivos que incluyen texto escrito, fotos de edificios, ilustraciones, bocetos o fotos de cajas de productos (con contornos nítidos y texto escrito en ella) generalmente entran dentro de esa categoría. Los motivos con transiciones de color y contraste más suaves, como paisajes o retratos, se pueden comprimir un poco más sin perder calidad visible. Las fotografías de la naturaleza generalmente entran en esa categoría.

Además, según dónde se utilice la imagen, es posible que desee utilizar un parámetro diferente. Una miniatura pequeña en un teaser puede soportar una mejor compresión que la misma imagen utilizada en un banner a pantalla completa. Esto significa que el parámetro de calidad no es innato de la imagen, sino de la imagen y el contexto. Y al gusto del autor.

En resumen: no hay un escenario perfecto para todas las imágenes. No hay una talla única para todos. Es mejor que el autor decida. Modificará el parámetro "calidad" como propiedad del componente hasta que esté satisfecho con la calidad y no vaya más allá para no sacrificar ancho de banda.

Ahora tenemos un archivo binario en DAM y un componente, que proporciona una propiedad de calidad. ¿Qué aspecto debería tener la dirección URL? ¿Qué componente es responsable de la bobina?

Seguridad - Excursión

Filtrado de solicitudes

Dónde filtrar mejor

Al final del último capítulo señalamos la necesidad de filtrar el tráfico entrante para los selectores conocidos. Esto deja la pregunta: ¿Dónde debería filtrar realmente las solicitudes?

Bueno, depende. Cuanto antes, mejor.

Cortafuegos de aplicaciones web

Si dispone de un dispositivo Web Application Firewall o "WAF" diseñado para Web Security, debe aprovechar estas funciones. Pero es posible que descubra que el WAF es operado por personas con conocimiento limitado de su aplicación de contenido y que filtran solicitudes válidas o dejan pasar demasiadas solicitudes dañinas. Tal vez descubra que las personas que operan el WAF están asignadas a un departamento diferente con diferentes turnos y horarios de lanzamiento, la comunicación podría no ser tan estrecha como con sus compañeros directos y no siempre se obtienen los cambios en el tiempo, lo que significa que en última instancia su desarrollo y velocidad de contenido sufren.

Podría terminar con unas cuantas reglas generales o incluso una lista de bloqueados, que según su instinto, podría ser más estricta.

Filtrado de Dispatcher y Publish

El siguiente paso es añadir reglas de filtrado de URL en el núcleo de Apache y/o en Dispatcher.

Aquí solo tiene acceso a las direcciones URL. Se limitan a filtros basados en patrones. Si necesita configurar un filtrado más basado en contenido (como permitir archivos solo con una marca de tiempo correcta) o quiere que parte del filtrado se controle en su Author, terminará escribiendo algo como un filtro servlet personalizado.

Configuración de dominios de invalidación con /statfileslevel

Cuando introdujimos la invalidación automática y el archivo de estado dijimos que todos los archivos se consideran no válidos cuando hay algún cambio y que todos los archivos son interdependientes de todos modos.

Eso no es del todo exacto. Normalmente, todos los archivos que comparten una raíz de navegación principal común son interdependientes. AEM Sin embargo, una instancia de puede alojar varios sitios web: independientes. No compartir una navegación común - de hecho, no compartir nada.

¿No sería un desperdicio en invalidar el Sitio B porque hay un cambio en el Sitio A? Sí, lo es. Y no tiene por qué ser así.

Dispatcher proporciona un medio sencillo para separar los sitios entre sí: statfiles-level.

Es un número que define a partir de qué nivel del sistema de archivos, dos subárboles se consideran "independientes".

Veamos el caso predeterminado en el que el nivel de archivo de estado es 0.

/statfileslevel "0":: el archivo .stat se crea en docroot. El dominio de invalidación abarca toda la instalación, incluidos todos los sitios.

Independientemente del archivo que se invalide, el archivo .stat en la parte superior del docroot de Dispatchers siempre se actualiza. Por lo tanto, al invalidar /content/site-b/home, también se invalidarán todos los archivos de /content/site-a, ya que ahora son más antiguos que el archivo .stat del docroot. Claramente no es lo que necesita, cuando invalida site-b.

En este ejemplo, preferiría establecer statfileslevel en 1.

Ahora, si publica y, por lo tanto, invalida /content/site-b/home o cualquier otro recurso por debajo de /content/site-b, el archivo .stat se creará en /content/site-b/.

El contenido por debajo de /content/site-a/ no se ve afectado. Este contenido se compararía con un archivo de .stat en /content/site-a/. Hemos creado dos dominios de invalidación independientes.

Un statfileslevel "1" crea dominios de invalidación diferentes

Las instalaciones grandes suelen estar estructuradas un poco más complejas y profundas. Un esquema común es estructurar los sitios por marca, país e idioma. En ese caso, puede establecer el nivel de archivos de estado aún más alto. 1 crearía dominios de invalidación por marca, 2 por país y 3 por idioma.

Conclusión

Hemos visto algunos principios básicos sobre el funcionamiento de Dispatcher en general y le hemos dado algunos ejemplos en los que podría tener que realizar un poco más de esfuerzo de implementación para hacerlo correctamente y en los que podría querer realizar concesiones.

No hemos entrado en detalles sobre cómo se configura en Dispatcher. Queremos que entienda los conceptos básicos y los problemas primero, sin perderle a la consola demasiado pronto. Y, el trabajo de configuración real está bien documentado: si comprende los conceptos básicos, debe saber para qué se utilizan los distintos conmutadores.

Sugerencias y trucos para Dispatcher

Concluiremos la primera parte de este libro con una colección aleatoria de pistas y trucos que podrían ser útiles en una situación u otra. Como hicimos antes, no estamos presentando la solución, sino la idea para que tenga la oportunidad de entender la idea y el concepto y el vínculo a artículos que describen la configuración real con más detalle.

Corregir intervalos de invalidación

AEM Si instala un Autor de y Publish de forma predeterminada, la topología es un poco extraña. El autor envía el contenido a los sistemas de Publish y la solicitud de invalidación a las instancias de Dispatcher al mismo tiempo. Como tanto los sistemas de Publish como el Dispatcher están separados del autor por colas, el tiempo puede ser un poco desafortunado. Dispatcher puede recibir la solicitud de invalidación del autor antes de actualizar el contenido en el sistema de Publish.

Si un cliente solicita ese contenido mientras tanto, Dispatcher solicitará y almacenará contenido antiguo.

Una configuración más confiable está enviando la solicitud de invalidación desde los sistemas Publish después de que hayan recibido el contenido. El artículo "Invalidación de la caché de Dispatcher desde una instancia de publicación" describe los detalles.

Referencias

helpx.adobe.com - Invalidando la caché de Dispatcher desde una instancia de publicación

Un período de gracia determinista

Nos gustaría introducir otra idea de cómo podría capear una tormenta de invalidación. Es sólo una idea. No lo hemos probado en producción, pero encontramos el concepto lo suficientemente interesante como para compartir la idea con ustedes.

gracePeriod puede llegar a ser impredeciblemente largo, si el intervalo de replicación regular es más corto que gracePeriod.

La idea alternativa es la siguiente: invalidar solo en intervalos de tiempo fijos. El tiempo intermedio siempre significa ofrecer contenido antiguo. La invalidación se producirá con el tiempo, pero se recopilan varias invalidaciones para una invalidación "masiva", de modo que Dispatcher tenga la oportunidad de servir contenido en caché mientras tanto y darle al sistema de Publish algo de aire para respirar.

La implementación tendría este aspecto:

Utiliza una "Secuencia de comandos de invalidación personalizada" (consulte la referencia) que se ejecutaría después de producirse la invalidación. Este script leería la fecha de la última modificación de statfile's y la redondearía hasta la siguiente parada de intervalo. El comando de shell de Unix touch --time, le permite especificar una hora.

Por ejemplo, si establece el período de gracia en 30 segundos, Dispatcher redondeará la última fecha de modificación del archivo de estado a los siguientes 30 segundos. Las solicitudes de invalidación que se producen entre una y otra simplemente establecen los mismos 30 segundos completos siguientes.

Si se pospone la invalidación hasta los siguientes 30 segundos completos, aumenta la tasa de aciertos.

Las visitas de caché que se producen entre la solicitud de invalidación y la siguiente ranura de ronda de 30 segundos se consideran obsoletas. Se ha producido una actualización en Publish, pero el Dispatcher sigue ofreciendo contenido antiguo.

Este enfoque podría ayudar a definir periodos de gracia más largos sin tener que temer que las solicitudes posteriores prolonguen el periodo de forma indeterminista. Aunque como dijimos antes - es solo una idea y no tuvimos la oportunidad de probarla.

Referencias

helpx.adobe.com - Configuración de Dispatcher