Capitolo 1 - Concetti, modelli e antipatemi di Dispatcher

URL suffisso in conflitto

Considera di disporre di due URL validi

http://domain.com/home.html

e

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

Sono assolutamente validi nell'AEM. Non vedrai alcun problema sul tuo computer di sviluppo locale (senza un Dispatcher). Molto probabilmente non incontrerai alcun problema nei test UAT o di carico. Il problema che stiamo affrontando è così sottile che passa attraverso la maggior parte dei test. Ti colpirà duramente quando sei al momento di picco e hai un tempo limitato per affrontarlo, probabilmente non hai accesso al server e non disponi di risorse per correggerlo. Siamo stati lì…

Allora… qual è il problema?

home.html in un file system può essere un file o una cartella. Non entrambi contemporaneamente all’AEM.

Se prima richiedi home.html, verrà creato come file.

Le richieste successive a home.html/suffix.html restituiscono risultati validi, ma poiché il file home.html "blocca" la posizione nel file system, home.html non può essere creato una seconda volta come cartella e pertanto home.html/suffix.html non è memorizzato nella cache.

Posizione di blocco dei file nel file system che impedisce la memorizzazione nella cache delle risorse secondarie

Se si esegue questa operazione al contrario, richiedendo prima home.html/suffix.html, suffix.html viene memorizzato nella cache in una cartella /home.html. Tuttavia, questa cartella viene eliminata e sostituita da un file home.html quando successivamente si richiede home.html come risorsa.

Eliminazione di una struttura di percorso quando un elemento padre viene recuperato come risorsa

Pertanto, il risultato di ciò che viene memorizzato in cache è completamente casuale e dipende dall’ordine delle richieste in arrivo. Ciò che rende le cose ancora più complicate è il fatto che di solito si ha più di un dispatcher. Inoltre, le prestazioni, il tasso di hit della cache e il comportamento potrebbero variare in modo diverso da un Dispatcher all’altro. Se vuoi scoprire perché il tuo sito web non risponde, devi assicurarti di guardare il Dispatcher corretto con lo sfortunato ordine di memorizzazione in cache. Se stai cercando il Dispatcher che - per fortuna - aveva un modello di richiesta più favorevole, andrai perso nel tentativo di trovare il problema.

Implementazione dell’annullamento automatico della validità: il file .stat

Ora, se si dispone di un sito di grandi dimensioni con migliaia di pagine, ci vorrebbe un po' di tempo per eseguire un ciclo tra tutte le pagine ed eliminarle fisicamente. Durante questo periodo, Dispatcher potrebbe distribuire involontariamente contenuti non aggiornati. Ancora peggio, potrebbero verificarsi alcuni conflitti durante l’accesso ai file della cache, ad esempio una pagina viene richiesta mentre è in corso la sua eliminazione o una pagina viene eliminata di nuovo a causa di un secondo annullamento della validità che si è verificato dopo un’attivazione immediatamente successiva. Considera che casino sarebbe. Fortunatamente questo non è quello che succede. Dispatcher utilizza un trucco intelligente per evitare che: invece di eliminare centinaia e migliaia di file, inserisce un file semplice e vuoto nella radice del file system quando un file viene pubblicato e quindi tutti i file dipendenti vengono considerati non validi. Questo file è denominato "statfile". Lo statfile è un file vuoto - ciò che conta sullo statfile è solo la sua data di creazione.

Tutti i file nel dispatcher, che hanno una data di creazione precedente allo statfile, sono stati renderizzati prima dell’ultima attivazione (e invalidamento) e sono quindi considerati "non validi". Sono ancora fisicamente presenti nel file system, ma la Dispatcher li ignora. Sono "obsoleti". Ogni volta che viene effettuata una richiesta a una risorsa non aggiornata, il Dispatcher chiede al sistema AEM di eseguire nuovamente il rendering della pagina. La pagina appena sottoposta a rendering viene quindi memorizzata nel file system, ora con una nuova data di creazione ed è di nuovo aggiornata.

La data di creazione del file .stat definisce quale contenuto è obsoleto e quale fresco

Potresti chiederti perché si chiama ".stat"? E forse non ".invalidato"? Beh, puoi immaginare che l'inserimento di questo file nel file system aiuti Dispatcher a determinare quali risorse potrebbero essere servite staticamente, proprio come da un server web statico. Non è più necessario eseguire il rendering dinamico di questi file.

La vera natura del nome, tuttavia, è meno metaforica. Deriva dalla chiamata di sistema Unix stat(), che restituisce il tempo di modifica di un file (tra le altre proprietà).

Convalida semplice e automatica

Ma aspettate… prima abbiamo detto, che singole risorse vengono cancellate fisicamente. Ora diciamo, che uno statfile più recente li renderebbe virtualmente non validi agli occhi del Dispatcher. Perché allora l'eliminazione fisica, prima?

La risposta è semplice. Di solito si utilizzano entrambe le strategie in parallelo, ma per diversi tipi di risorse. Le risorse binarie, come le immagini, sono autonome. Non sono connesse ad altre risorse, nel senso che hanno bisogno delle loro informazioni per essere rese.

Le pagine HTML, invece, sono altamente interdipendenti. Quindi, puoi applicare l’annullamento automatico della validità a questi. Questa è l’impostazione predefinita in Dispatcher. Tutti i file appartenenti a una risorsa invalidata vengono eliminati fisicamente. Inoltre, i file che terminano con ".html" vengono invalidati automaticamente.

Il Dispatcher decide sull’estensione del file se applicare o meno lo schema di invalidazione automatica.

È possibile configurare le terminazioni dei file per l’annullamento automatico della validità. In teoria, puoi includere tutte le estensioni all’annullamento automatico della validità. Ma tenete presente che il prezzo è molto alto. Non vedrai risorse obsolete consegnate involontariamente, ma le prestazioni di consegna si riducono notevolmente a causa di un annullamento eccessivo della validità.

Immagina, ad esempio, di implementare uno schema in cui i PNG e i JPG dell’vengono sottoposti a rendering in modo dinamico e dipendono da altre risorse per farlo. È possibile ridimensionare le immagini ad alta risoluzione a una risoluzione compatibile con il Web più piccola. Mentre ci sei, cambia anche il tasso di compressione. La risoluzione e il tasso di compressione in questo esempio non sono costanti fisse, ma parametri configurabili nel componente che utilizza l’immagine. Ora, se questo parametro viene modificato, devi invalidare le immagini.

Nessun problema - abbiamo appena appreso che potevamo aggiungere immagini all’annullamento automatico della validità e avere sempre immagini appena riprodotte ogni volta che qualcosa cambia.

Gettare via il bambino con l'acqua

Esatto, e questo è un problema enorme. Leggete di nuovo l'ultimo paragrafo. "…immagini appena riprodotte ogni volta che cambia qualcosa." Come sai, un buon sito web viene modificato costantemente; aggiungendo nuovi contenuti qui, correggendo un errore di battitura lì, modificando un teaser da qualche altra parte. Ciò significa che tutte le immagini vengono invalidate costantemente e devono essere sottoposte a rendering. Non sottovalutatelo. Il rendering e il trasferimento dinamico dei dati immagine funzionano in millisecondi sul computer di sviluppo locale. L’ambiente di produzione deve farlo con una frequenza cento volte superiore, al secondo.

E siamo chiari qui, i file jpg devono essere renderizzati nuovamente, quando cambia una pagina HTML e viceversa. Esiste un solo "bucket" di file da invalidare automaticamente. Viene scaricato nel suo insieme. Senza la necessità di suddividerli in strutture più dettagliate.

Esiste un buon motivo per cui l’annullamento automatico della validità viene mantenuto su ".html" per impostazione predefinita. L’obiettivo è quello di mantenere quel bucket il più piccolo possibile. Non gettare il bambino con l'acqua di balneazione semplicemente invalidando tutto - solo per essere sul lato sicuro.

Le risorse autonome devono essere distribuite nel percorso della risorsa. Questo aiuta molto l'invalidazione. Semplificalo, non creare schemi di mappatura come "resource /a/b/c" is serving from "/x/y/z". Assicurati che i componenti funzionino con le impostazioni di annullamento automatico della validità predefinite di Dispatcher. Non cercare di riparare un componente progettato in modo errato con l’annullamento eccessivo della validità in Dispatcher.

Creazione di componenti pensando al Dispatcher

Applicazione della meccanica Dispatcher in un esempio reale

Nell'ultimo capitolo abbiamo spiegato i meccanismi di base di Dispatcher, il suo funzionamento in generale e i suoi limiti.

Ora vogliamo applicare queste meccaniche a un tipo di componenti che molto probabilmente troverai nei requisiti del tuo progetto. Il componente viene scelto appositamente per illustrare i problemi che dovrai affrontare prima o poi. Non abbiate paura - non tutte le componenti hanno bisogno della quantità di considerazione che presenteremo. Ma se vedi la necessità di costruire un tale componente, sei ben consapevole delle conseguenze e sai come gestirle.

Motivo del componente di spooling (anti)

Il componente Immagine reattivo

Illustriamo un pattern comune (o anti-pattern) di un componente con binari interconnessi. Creeremo un componente "respi" per "responsive-image". Questo componente deve essere in grado di adattare l’immagine visualizzata al dispositivo su cui viene visualizzata. Su desktop e tablet mostra la piena risoluzione dell'immagine, su telefoni una versione più piccola con un ritaglio stretto - o forse anche un motivo completamente diverso (questo è chiamato "art direction" nel mondo reattivo).

Le risorse vengono caricate nell'area DAM dell'AEM e solo a cui si fa riferimento nel componente responsive-image.

Il componente respi si occupa sia del rendering del markup che della distribuzione dei dati dell’immagine binaria.

Il modo in cui lo implementiamo qui è un modello comune che abbiamo visto in molti progetti e anche uno dei componenti core dell'AEM si basa su questo modello. Pertanto, è molto probabile che voi come sviluppatore possiate adattare quel modello. Ha i suoi punti dolci in termini di incapsulamento, ma richiede un grande sforzo per renderlo Dispatcher-ready. In seguito verranno illustrate diverse opzioni per mitigare il problema.

Chiamiamo il modello usato qui il "modello spooler", perché il problema risale ai primi giorni del comunicato 3 dove c'era un metodo "spooler" che poteva essere chiamato su una risorsa per trasmettere i suoi dati binari nella risposta.

Il termine originale "spooling" in realtà si riferisce a periferiche offline lente condivise, come le stampanti, quindi non viene applicato correttamente in questo punto. Ma ci piace il termine comunque perché è raramente nel mondo online quindi distinguibile. E ogni schema dovrebbe avere un nome distinguibile, giusto? Sta a te decidere se si tratta di un pattern o di un anti-pattern.

Conclusione

Dal punto di vista di uno sviluppatore di AEM il modello sembrava super elegante. Ma con il Dispatcher preso in considerazione l'equazione, potreste essere d'accordo, che l'approccio ingenuo potrebbe non essere sufficiente.

Per il momento, lasciamo a voi la scelta di decidere se si tratta di uno schema o di un anti-schema. E forse hai già in mente alcune buone idee su come mitigare i problemi spiegati sopra? Bene. Poi dovresti essere ansioso di vedere come altri progetti hanno risolto questi problemi.

Risoluzione dei problemi comuni di Dispatcher

Panoramica

Parliamo di come questo avrebbe potuto essere implementato in modo un po' più semplice da memorizzare nella cache. Sono disponibili diverse opzioni. A volte non è possibile scegliere la soluzione migliore. Magari entri in un progetto già in esecuzione e hai un budget limitato per risolvere semplicemente il "problema della cache" a portata di mano e non abbastanza per eseguire un refactoring completo. Oppure si affronta un problema, che è un più complesso del componente immagine di esempio.

Nelle sezioni seguenti verranno illustrati i principi e le avvertenze.

Anche in questo caso, si basa su esperienze reali. Abbiamo già visto tutti questi schemi in natura, quindi non è un esercizio accademico. Questo è il motivo per cui vi stiamo mostrando alcuni anti-pattern, in modo da avere la possibilità di imparare dagli errori che altri hanno già fatto.

Impronta digitale URL

L'impronta digitale di un URL è simile a un cache-killer. Ma non lo è. Non è un numero casuale, ma un valore che caratterizza il contenuto della risorsa. Può trattarsi di un hash del contenuto della risorsa o, ancor più semplice, di una marca temporale in cui la risorsa è stata caricata, modificata o aggiornata.

Una marca temporale Unix è sufficiente per un’implementazione reale. Per una migliore leggibilità, si utilizza un formato più leggibile in questa esercitazione: 2018 31.12 23:59 or fp-2018-31-12-23-59.

L’impronta digitale non deve essere utilizzata come parametro di query, in quanto gli URL con parametri di query non può essere memorizzato nella cache. È possibile utilizzare un selettore o il suffisso per l'impronta digitale.

Supponiamo che il file /content/dam/flower.jpg abbia una data jcr:lastModified il 31 dicembre 2018, alle 23:59. L'URL con l'impronta digitale è /content/home/jcr:content/par/respi.fp-2018-31-12-23-59.jpg.

L'URL rimane stabile finché il file della risorsa di riferimento (flower.jpg) non viene modificato. Quindi può essere memorizzato nella cache per un periodo di tempo indefinito e non è un cache killer.

Nota: questo URL deve essere creato e gestito dal componente immagine reattivo. Non è una funzionalità AEM preconfigurata.

Questo è il concetto di base. Ci sono tuttavia alcuni dettagli che potrebbero facilmente essere trascurati.

Nel nostro esempio, il componente è stato renderizzato e memorizzato nella cache alle 23:59. Ora l’immagine è stata modificata, diciamo alle 00:00. Il componente avrebbe generato un nuovo URL impresso nel relativo markup.

Potresti pensare che dovrebbe… ma non è così. Poiché è stato modificato solo il binario dell’immagine e la pagina inclusa non è stata toccata, non è necessario eseguire nuovamente il rendering del markup HTML. Quindi, il Dispatcher serve la pagina con la vecchia impronta digitale, e quindi la vecchia versione dell'immagine.

Componente immagine più recente dell'immagine a cui si fa riferimento, nessuna nuova impronta digitale sottoposta a rendering.

Ora, se hai riattivato la home page (o qualsiasi altra pagina del sito), lo statfile verrà aggiornato, Dispatcher considererà il file home.html obsoleto e lo rieseguirà con una nuova impronta digitale nel componente immagine.

Ma non abbiamo attivato la home page, giusto? E perché dovremmo attivare una pagina che non abbiamo toccato comunque? Inoltre, forse non disponiamo di diritti sufficienti per attivare le pagine o il flusso di lavoro di approvazione è così lungo e dispendioso in termini di tempo che non possiamo farlo con breve preavviso. Allora… cosa fare?

Break Break

Wow - Ci sono molti dettagli da considerare, giusto? E si rifiuta di essere compreso, testato e debuggato facilmente. E tutto per una soluzione apparentemente elegante. Certo, è elegante, ma solo dal punto di vista dell'AEM. Insieme alla Dispatcher, la situazione è deprimente.

Tuttavia, questo non risolve un problema di base: se un’immagine viene utilizzata più volte su pagine diverse, vengono memorizzate nella cache sotto tali pagine. Non c'è molta sinergia nella cache.

In generale, il rilevamento delle impronte digitali degli URL è un buon strumento da avere nel toolkit, ma devi applicarlo con cautela, perché può causare nuovi problemi e al contempo risolvere solo alcuni problemi esistenti.

Quindi… è stato un lungo capitolo. Ma abbiamo visto questo schema così spesso, che abbiamo sentito che è necessario darvi l'intera immagine con tutti i pro e i contro. Le impronte digitali dell’URL risolvono alcuni dei problemi inerenti al pattern di spooler, ma lo sforzo di implementazione è piuttosto elevato e devi prendere in considerazione anche altre soluzioni più facili. Consigliamo di verificare sempre se è possibile basare gli URL sui percorsi delle risorse fornite e non disporre di un componente intermedio. Ci occuperemo di questo nel prossimo capitolo.

Risoluzione dipendenze runtime

Runtime Dependency Resolution è un concetto che abbiamo preso in considerazione in un progetto. Ma ripensarla è diventato piuttosto complesso e abbiamo deciso di non attuarlo.

Ecco l'idea di base:

Dispatcher non è a conoscenza delle dipendenze delle risorse. È solo una serie di file singoli con poca semantica.

Anche l'AEM sa poco sulle dipendenze. Manca di una semantica corretta o di un "tracciatore delle dipendenze".

L'AEM è a conoscenza di alcuni riferimenti. Utilizza questa conoscenza per avvisarti quando tenti di eliminare o spostare una pagina o una risorsa di riferimento. A tale scopo, esegue una query sulla ricerca interna al momento dell’eliminazione di una risorsa. I riferimenti ai contenuti hanno un modulo molto particolare. Sono espressioni di percorso che iniziano con "/content". Pertanto, possono essere facilmente indicizzati full-text e interrogati quando necessario.

Nel nostro caso, avremmo bisogno di un agente di replica personalizzato sul sistema Publish, che attivi la ricerca di un percorso specifico quando quel percorso è stato modificato.

Diciamo che

/content/dam/flower.jpg

È cambiato su Publish. L'agente attiverebbe una ricerca per "/content/dam/flower.jpg" e troverebbe tutte le pagine che fanno riferimento a tali immagini.

Potrebbe quindi inviare una serie di richieste di annullamento della validità al Dispatcher. Uno per ogni pagina contenente la risorsa.

In teoria, dovrebbe funzionare. Ma solo per le dipendenze di primo livello. Non vorresti applicare tale schema per dipendenze a più livelli, ad esempio quando utilizzi l’immagine su un frammento di esperienza utilizzato in una pagina. In realtà, riteniamo che questo approccio sia troppo complesso - e ci potrebbero essere problemi di run-time. E in genere il consiglio migliore è quello di non fare il calcolo costoso nei gestori di eventi. E soprattutto la ricerca può diventare piuttosto costosa.

Conclusione

Ci auguriamo di aver discusso a fondo il pattern dello spooler in modo da aiutarti a decidere quando utilizzarlo e non utilizzarlo nella tua implementazione.

Evitare i problemi di Dispatcher

URL basati su risorse

Un modo molto più elegante per risolvere il problema della dipendenza è quello di non avere alcuna dipendenza. Evita le dipendenze artificiali che si verificano quando utilizzi una risorsa per fungerne semplicemente il proxy, come abbiamo fatto nell’ultimo esempio. Prova a vedere le risorse come entità "solitarie" il più spesso possibile.

Il nostro esempio è facilmente risolvibile:

Spooling dell'immagine con un servlet associato all'immagine, non al componente.

Utilizziamo i percorsi delle risorse originali per eseguire il rendering dei dati. Per riprodurre l’immagine originale così com’è, possiamo semplicemente utilizzare il renderer predefinito AEM per le risorse.

Se è necessario eseguire un’elaborazione speciale per un componente specifico, viene registrato un servlet dedicato nel percorso e un selettore per eseguire la trasformazione per conto del componente. L'abbiamo fatto qui esemplare con il ".respi." selettore. È consigliabile tenere traccia dei nomi dei selettori utilizzati nello spazio URL globale (ad esempio /content/dam) e avere una buona convenzione di denominazione per evitare conflitti di denominazione.

A proposito - non vediamo alcun problema con la coerenza del codice. Il servlet può essere definito nello stesso pacchetto Java del modello sling dei componenti.

Possiamo anche utilizzare selettori aggiuntivi nello spazio globale, ad esempio,

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

Facile, vero? Allora perché la gente ha modelli complicati come lo Spooler?

Beh, potremmo risolvere il problema evitando il riferimento al contenuto interno perché il componente esterno aggiungeva poco valore o informazioni al rendering della risorsa interna, e poteva facilmente essere codificato in un set di selettori statici che controllano la rappresentazione di una risorsa solitaria.

Tuttavia, esiste una classe di casi che non è possibile risolvere facilmente con un URL basato su risorse. Questo tipo di caso, denominato "Componenti per iniezione di parametri", viene discusso nel capitolo successivo.

Parametro per l'inserimento di componenti

Panoramica

Lo spooler nell’ultimo capitolo era solo un sottile wrapper intorno a una risorsa. Ha causato più problemi che aiutare a risolverli.

Potremmo facilmente sostituire tale wrapping utilizzando un semplice selettore e aggiungere un servlet corrispondente per soddisfare tali richieste.

Ma cosa succede se il componente "respi" è più di un semplice proxy? Cosa succede se il componente contribuisce realmente al rendering del componente?

Introduciamo una piccola estensione del nostro componente "respi", che è un po' un cambio di gioco. Anche in questo caso, introdurremo prima alcune soluzioni ingenue per affrontare le nuove sfide e mostrare dove non sono all'altezza.

Il componente Respi2

Il componente respi2 è un componente che visualizza un’immagine reattiva, così come il componente respi. Ma ha un piccolo componente aggiuntivo,

Struttura di CRX: componente respi2 che aggiunge una proprietà di qualità alla consegna

Le immagini sono jpeg e i jpeg possono essere compressi. Quando comprimete un'immagine JPEG, si scambia la qualità in base alle dimensioni del file. La compressione è definita come un parametro numerico di "qualità" che va da "1" a "100". "1" significa "file piccoli ma di scarsa qualità", "100" significa "file di qualità eccellente ma di grandi dimensioni". Quindi qual è il valore perfetto?

Come in tutte le cose informatiche, la risposta è: "Dipende".

Qui dipende dal motivo. I motivi con bordi ad alto contrasto come motivi, tra cui testo scritto, foto di edifici, illustrazioni, schizzi o foto di scatole di prodotti (con contorni nitidi e testo scritto su di esso) di solito rientrano in tale categoria. I motivi con transizioni di colore e contrasto più morbide, come paesaggi o ritratti, possono essere compressi un po' di più senza perdita di qualità visibile. Le fotografie naturalistiche di solito rientrano in tale categoria.

Inoltre, a seconda della posizione in cui viene utilizzata l’immagine, potrebbe essere utile utilizzare un parametro diverso. Una piccola miniatura in un teaser potrebbe sopportare una compressione migliore rispetto alla stessa immagine utilizzata in un banner hero a tutto schermo. Ciò significa che il parametro di qualità non è innato all’immagine, ma all’immagine e al contesto. E secondo i gusti dell'autore.

In breve: non esiste un'impostazione perfetta per tutte le immagini. Non esiste un modello universale. È meglio che lo decida l'autore. Modificherà il parametro "quality" come proprietà nel componente fino a quando non sarà soddisfatto della qualità e non si sposterà oltre per non sacrificare la larghezza di banda.

Ora disponiamo di un file binario in DAM e di un componente che fornisce una proprietà di qualità. Come deve apparire l’URL? Quale componente è responsabile dello spooling?

Sicurezza - Escursione

Filtraggio delle richieste

Dove filtrare meglio

Alla fine dell’ultimo capitolo abbiamo sottolineato la necessità di filtrare il traffico in entrata per i selettori noti. Rimane la domanda: dove dovrei filtrare le richieste?

Beh, dipende. Prima è meglio è.

Firewall applicazione Web

Se si dispone di un accessorio Web Application Firewall o "WAF" progettato per la sicurezza Web, è assolutamente necessario sfruttare queste funzionalità. Tuttavia, potresti scoprire che il WAF è gestito da persone con una conoscenza limitata dell’applicazione dei contenuti e che filtrano le richieste valide o lasciano passare troppe richieste dannose. Forse scoprirai che le persone che gestiscono la WAF sono assegnate a un reparto diverso con turni e pianificazioni di rilascio diversi, la comunicazione potrebbe non essere così stretta come con i tuoi diretti compagni di squadra e non sempre si ottengono i cambiamenti nel tempo, il che significa che alla fine lo sviluppo e la velocità dei contenuti soffrono.

Potresti finire con qualche regola generale o anche un inserisco nell'elenco Bloccati di, che il tuo istinto dice, potrebbe essere reso più rigido.

Filtro Dispatcher e Publish

Il passaggio successivo consiste nell’aggiungere regole di filtro URL nel core Apache e/o in Dispatcher.

Qui puoi accedere solo agli URL. Puoi usare solo filtri basati su pattern. Se devi impostare un filtro più basato sul contenuto (ad esempio, consentire i file solo con una marca temporale corretta) o desideri che parte del filtro sia controllato sull’autore, finirai per scrivere qualcosa come un filtro servlet personalizzato.

Impostazione dei domini di invalidazione con /statfileslevel

Quando abbiamo introdotto l'annullamento automatico della validità e lo statfile abbiamo detto che tutti i file sono considerati non validi in presenza di modifiche e che tutti i file sono comunque interdipendenti.

Non è del tutto accurato. In genere, tutti i file che condividono una directory principale di navigazione comune sono interdipendenti. Ma un'istanza AEM può ospitare diversi siti Web: siti Web indipendenti. Non condividendo una navigazione comune; infatti non condividendo nulla.

Non sarebbe un rifiuto per invalidare il Sito B perché c'è una modifica nel Sito A? Sì, lo è. E non deve per forza essere così.

Dispatcher fornisce un semplice mezzo per separare i siti tra loro: statfiles-level.

È un numero che definisce da quale livello nel filesystem in poi, due sottoalberi sono considerati "indipendenti".

Vediamo il caso predefinito in cui statfileslevel è 0.

/statfileslevel "0": Il file .stat è stato creato nella directory principale dei documenti. Il dominio di annullamento della validità si estende sull'intera installazione, inclusi tutti i siti.

A prescindere dal file invalidato, il file .stat nella parte superiore della directory principale dei documenti di Dispatcher viene sempre aggiornato. Quando si invalida /content/site-b/home, vengono invalidati anche tutti i file in /content/site-a, in quanto sono più vecchi del file .stat nella directory principale dei documenti. Chiaramente non è ciò di cui hai bisogno quando annulli la validità di site-b.

In questo esempio è preferibile impostare statfileslevel su 1.

Ora, se pubblichi - e quindi invalidi /content/site-b/home o qualsiasi altra risorsa sotto /content/site-b, il file .stat viene creato in /content/site-b/.

Il contenuto inferiore a /content/site-a/ non è interessato. Il contenuto viene confrontato con un file .stat in /content/site-a/. Sono stati creati due domini di invalidazione separati.

Il livello statfileslevel "1" crea domini di invalidazione diversi

Le installazioni di grandi dimensioni sono in genere strutturate in modo più complesso e profondo. Un sistema comune consiste nel strutturare i siti per marchio, paese e lingua. In tal caso, è possibile impostare statfileslevel ancora più alto. 1 creerebbe domini di invalidazione per marchio, 2 per paese e 3 per lingua.

Conclusione

Abbiamo trattato alcuni principi di base sul funzionamento generale di Dispatcher e vi abbiamo fornito alcuni esempi in cui potreste dover lavorare un po' di più sull'implementazione per risolvere il problema e dove potreste voler fare dei compromessi.

Non sono stati forniti dettagli su come è configurato in Dispatcher. Volevamo capire i concetti di base e i problemi, senza perdere tempo per usare la console troppo presto. Inoltre, se si conoscono i concetti di base, è necessario conoscere le funzioni dei vari switch.

Suggerimenti e trucchi per Dispatcher

Concluderemo la prima parte di questo libro con una raccolta casuale di suggerimenti e trucchi che potrebbero essere utili in una situazione o in un'altra. Come abbiamo fatto in precedenza, non presentiamo la soluzione, ma l'idea in modo da avere la possibilità di comprendere l'idea e il concetto e collegare agli articoli che descrivono la configurazione effettiva in modo più dettagliato.

Correggi tempi di invalidazione

Se installi un autore di AEM e Publish preconfigurato, la topologia è un po' strana. L’autore invia contemporaneamente il contenuto ai sistemi Publish e la richiesta di annullamento della validità ai Dispatcher. Poiché sia i sistemi Publish che il Dispatcher sono separati dall'Autore dalle code, la tempistica può essere un po' sfortunata. Dispatcher può ricevere la richiesta di annullamento della validità dall’autore prima che il contenuto venga aggiornato sul sistema Publish.

Se un client richiede tale contenuto nel frattempo, Dispatcher richiederà e memorizzerà il contenuto non aggiornato.

Una configurazione più affidabile sta inviando la richiesta di annullamento della validità dai sistemi Publish dopo che hanno ricevuto il contenuto. L'articolo "Annullamento della validità della cache di Dispatcher da un'istanza Publish" descrive i dettagli.

Riferimenti

helpx.adobe.com - Annullamento della validità della cache di Dispatcher da un'istanza Publish

Un periodo di tolleranza deterministico

Vorremmo introdurre un'altra idea su come superare una tempesta di invalidazione. È solo un'idea. Non l'abbiamo provato in produzione, ma abbiamo trovato il concetto abbastanza interessante da condividere l'idea con voi.

gracePeriod può diventare imprevedibilmente lungo, se l'intervallo di replica regolare è più breve di gracePeriod.

L’idea alternativa è la seguente: Invalida solo in intervalli di tempo fissi. Il tempo che intercorre tra le due opzioni significa sempre fornire contenuto non aggiornato. L’invalidazione avverrà alla fine, ma una serie di invalidazioni viene raccolta in un’unica invalidazione "in blocco", in modo che il Dispatcher abbia la possibilità di distribuire nel frattempo alcuni contenuti memorizzati nella cache e dare al sistema Publish un po’ di aria da respirare.

L’implementazione sarà simile alla seguente:

Utilizza uno "script di invalidazione personalizzato" (vedi riferimento) che viene eseguito dopo l’invalidazione. Questo script legge l'ultima data di modifica statfile's e la arrotonda alla successiva interruzione dell'intervallo. Comando Unix shell touch --time. Specificare un'ora.

Ad esempio, se imposti il periodo di tolleranza su 30 sec, Dispatcher arrotonderà l’ultima data modificata dello statfile ai successivi 30 sec. Le richieste di annullamento della validità che si verificano tra appena impostato gli stessi 30 secondi interi successivi.

Il posticipo dell'invalidazione al successivo periodo completo di 30 secondi aumenta la percentuale di hit.

Gli hit della cache che si verificano tra la richiesta di invalidazione e lo slot di 30 secondi del turno successivo vengono quindi considerati obsoleti. È stato effettuato un aggiornamento su Publish, ma Dispatcher fornisce ancora contenuti obsoleti.

Questo approccio potrebbe aiutare a definire periodi di tolleranza più lunghi senza dover temere che le richieste successive prolunghino il periodo in modo indeterministico. Anche se come abbiamo detto prima - è solo un'idea e non abbiamo avuto la possibilità di testarla.

Riferimenti

helpx.adobe.com - Configurazione Dispatcher