Il traffico passa attraverso la CDN a un livello di server web Apache, che supporta moduli incluso il dispatcher. Per migliorare le prestazioni, il dispatcher viene utilizzato principalmente come cache per limitare l’elaborazione sui nodi di pubblicazione.
Le regole possono essere applicate alla configurazione del dispatcher per modificare eventuali impostazioni di scadenza della cache predefinite, con conseguente memorizzazione in cache nella CDN. Tieni presente che il dispatcher rispetta anche le intestazioni di scadenza della cache risultanti se enableTTL
è abilitato nella configurazione del dispatcher, il che implica che aggiornerà contenuti specifici anche al di fuori del contenuto in fase di ripubblicazione.
Questa pagina descrive anche come la cache del dispatcher viene invalidata, nonché come funziona la memorizzazione in cache a livello di browser per quanto riguarda le librerie lato client.
cache-control
intestazione emessa dal livello apache. Anche la CDN rispetta questo valore.DISABLE_DEFAULT_CACHING
in global.vars
:Define DISABLE_DEFAULT_CACHING
Ciò può essere utile, ad esempio, quando la logica di business richiede una regolazione precisa dell’intestazione di pagina (con un valore basato sul giorno del calendario), in quanto per impostazione predefinita l’intestazione di pagina è impostata su 0. Detto questo, si prega di prestare attenzione quando si disattiva la memorizzazione in cache predefinita.
può essere ignorato per tutti i contenuti HTML/testo definendo la variabile EXPIRATION_TIME
in global.vars
utilizzando l’AEM come strumenti di Dispatcher SDK per Cloud Service.
possono essere sovrascritti a un livello più granulare dalle seguenti direttive mod_headers apache:
<LocationMatch "^/content/.*\.(html)$">
Header set Cache-Control "max-age=200"
Header set Age 0
</LocationMatch>
Fai attenzione quando imposti le intestazioni di controllo cache globale o quelle che corrispondono a un’area estesa in modo che non vengano applicate al contenuto che potresti voler mantenere privato. Valuta l’utilizzo di più direttive per garantire che le regole vengano applicate in modo dettagliato. Detto questo, AEM come Cloud Service rimuoverà l’intestazione della cache se rileva che è stata applicata a ciò che rileva come non può essere memorizzata nella cache dal dispatcher, come descritto nella documentazione del dispatcher. Per forzare AEM ad applicare sempre la memorizzazione in cache, è possibile aggiungere l’opzione "sempre" come segue:
<LocationMatch "^/content/.*\.(html)$">
Header always set Cache-Control "max-age=200"
Header set Age 0
</LocationMatch>
È necessario assicurarsi che un file in src/conf.dispatcher.d/cache
abbia la seguente regola (che si trova nella configurazione predefinita):
/0000
{ /glob "*" /type "allow" }
Per evitare che un contenuto specifico venga memorizzato nella cache, imposta l'intestazione Cache-Control su private. Ad esempio, quanto segue impedisce la memorizzazione nella cache del contenuto HTML in una directory denominata myfolder:
<LocationMatch "/content/myfolder/.*\.(html)$">. // replace with the right regex
Header set Cache-Control “private”
</LocationMatch>
Gli altri metodi, incluso il progetto ACS Commons AEM dispatcher-ttl, non sostituiranno correttamente i valori.
per impostazione predefinita, non memorizzato nella cache
può essere impostato a un livello più granulare dalle seguenti direttive apache mod_headers
:
<LocationMatch "^/content/.*\.(jpeg|jpg)$">
Header set Cache-Control "max-age=222"
Header set Age 0
</LocationMatch>
Consulta la discussione nella sezione html/text di cui sopra per fare attenzione a non memorizzare la cache troppo su larga scala e anche su come forzare AEM ad applicare sempre la memorizzazione in cache con l'opzione "sempre".
È necessario garantire che un file sotto src/conf.dispatcher.d/
cache abbia la seguente regola (che si trova nella configurazione predefinita):
/0000
{ /glob "*" /type "allow" }
Assicurati che le risorse da mantenere private anziché memorizzate nella cache non facciano parte dei filtri di direttiva LocationMatch.
Gli altri metodi, incluso il progetto ACS Commons AEM dispatcher-ttl, non sostituiranno correttamente i valori.
EXPIRATION_TIME
utilizzata per i tipi di file html/textIn generale, non sarà necessario annullare la validità della cache del dispatcher. Al contrario, dovresti affidarti all’aggiornamento della cache del dispatcher quando il contenuto viene ripubblicato e la CDN che rispetta le intestazioni di scadenza della cache.
Come nelle versioni precedenti di AEM, la pubblicazione o l’annullamento della pubblicazione di pagine cancella il contenuto dalla cache del dispatcher. Se si sospetta un problema di caching, i clienti devono ripubblicare le pagine in questione.
Quando l’istanza di pubblicazione riceve una nuova versione di una pagina o di una risorsa dall’autore, utilizza l’agente di eliminazione per annullare la validità dei percorsi appropriati sul proprio dispatcher. Il percorso aggiornato viene rimosso dalla cache del dispatcher, insieme ai relativi genitori, fino a un livello (puoi configurarlo con statfileslevel.
In generale, non sarà necessario annullare manualmente la validità del contenuto nel dispatcher, ma è possibile se necessario, come descritto di seguito.
Prima di AEM come Cloud Service, c'erano due modi per invalidare la cache del dispatcher.
invalidate.cache
(ad esempio, POST /dispatcher/invalidate.cache
)L’approccio API del dispatcher invalidate.cache
non sarà più supportato in quanto si rivolge solo a un nodo specifico del dispatcher. AEM come Cloud Service funziona a livello di servizio, non a livello di singolo nodo, pertanto le istruzioni di invalidazione nella pagina Invalidazione delle pagine in cache da AEM non sono più valide per AEM come Cloud Service .
È invece necessario utilizzare l'agente di scaricamento della replica. Questa operazione può essere eseguita utilizzando l’API di replica. La documentazione sulle API di replica è disponibile qui e per un esempio di scaricamento della cache, consulta la pagina di esempio API in particolare l’ esempio CustomStep
che invia un’azione di replica di tipo ACTIVATE a tutti gli agenti disponibili. L’endpoint dell’agente di scaricamento non è configurabile ma preconfigurato per puntare al dispatcher, con corrispondenza con il servizio di pubblicazione che esegue l’agente di scaricamento. L’agente di scaricamento può in genere essere attivato da eventi o flussi di lavoro OSGi.
Il diagramma che segue illustra questo aspetto.
Se si teme che la cache del dispatcher non venga cancellata, contatta il supporto clienti che può scaricare la cache del dispatcher se necessario.
La rete CDN gestita da Adobe rispetta i TTL e non è quindi necessario scaricarla. Se si sospetta un problema, contatta il supporto clienti che può eseguire il flush di una cache CDN gestita da Adobe, se necessario.
Le pagine sono composte da HTML, JavaScript, CSS e immagini. Invitiamo i clienti a sfruttare il framework Librerie lato client (clientlibs) per importare risorse Javascript e CSS nelle pagine HTML, tenendo conto delle dipendenze tra le librerie JS.
Il framework clientlibs fornisce una gestione automatica della versione, il che significa che gli sviluppatori possono archiviare le modifiche alle librerie JS nel controllo del codice sorgente e che la versione più recente sarà resa disponibile quando un cliente invia il rilascio. In caso contrario, gli sviluppatori dovranno modificare manualmente l’HTML con i riferimenti alla nuova versione della libreria, il che è particolarmente oneroso se molti modelli HTML condividono la stessa libreria.
Quando le nuove versioni delle librerie vengono rilasciate in produzione, le pagine HTML di riferimento vengono aggiornate con nuovi collegamenti alle versioni della libreria aggiornate. Una volta scaduta la cache del browser per una determinata pagina HTML, non c'è alcun problema che le vecchie librerie vengano caricate dalla cache del browser, poiché la pagina aggiornata (da AEM) ora è garantita per fare riferimento alle nuove versioni delle librerie. In altre parole, una pagina HTML aggiornata includerà tutte le versioni della libreria più recenti.
Il meccanismo di questo è un hash serializzato, che viene aggiunto al collegamento della libreria client, garantendo un URL univoco con versione affinché il browser memorizzi nella cache CSS/JS. L’hash serializzato viene aggiornato solo quando il contenuto della libreria client cambia. Ciò significa che se si verificano aggiornamenti non correlati (cioè nessuna modifica al css/js sottostante della libreria client) anche con una nuova distribuzione, il riferimento rimane lo stesso, garantendo una minore interruzione della cache del browser.
Le inclusioni clientlib predefinite su una pagina HTML hanno un aspetto simile al seguente:
<link rel="stylesheet" href="/etc.clientlibs/wkndapp/clientlibs/clientlib-base.css?lang=it" type="text/css">
Quando il controllo delle versioni di clientlib è abilitato, una chiave hash a lungo termine viene aggiunta come selettore alla libreria client. Di conseguenza, il riferimento a clientlib sarà simile al seguente:
<link rel="stylesheet" href="/etc.clientlibs/wkndapp/clientlibs/clientlib-base.lc-7c8c5d228445ff48ab49a8e3c865c562-lc.css?lang=it" type="text/css">
Il controllo delle versioni clientlib restrittive è abilitato per impostazione predefinita in tutti gli ambienti AEM come Cloud Service.
Per abilitare il controllo delle versioni di clientlib restrittive nell’SDK Quickstart locale, esegui le seguenti azioni:
<host>/system/console/configMgr