Informazioni sulle directory di caching

Ultimo aggiornamento: 2024-01-18

Questo documento spiega come avviene il caching di Dispatcher e come può essere configurato.

Descrizione

Ambiente
Adobe Experience Manager

Problema/Sintomi
Questo documento spiega come avviene il caching di Dispatcher e come può essere configurato.
Sommario

Risoluzione

Memorizzazione in cache delle directory

Nelle installazioni della linea di base vengono utilizzate le seguenti directory di cache predefinite

  • Autore

    • /mnt/var/www/author
  • Editore

    • /mnt/var/www/html

Quando ogni richiesta attraversa il dispatcher, le richieste seguono le regole configurate per mantenere una versione cache locale della risposta degli elementi idonei.

Nota:

Teniamo intenzionalmente il carico di lavoro pubblicato separato dal carico di lavoro dell’autore perché quando Apache cerca un file in DocumentRoot, non sa da quale istanza AEM proviene. Pertanto, anche se la cache è disabilitata nella farm di authoring, se DocumentRoot dell’autore è uguale a quello dell’editore, se presente i file verranno distribuiti dalla cache. Ciò significa che potrai distribuire i file di authoring dalla cache pubblicata e creare un’esperienza di mix davvero terribile per i visitatori. Anche mantenere directory DocumentRoot separate per contenuti pubblicati diversi è una pessima idea. Dovrai creare più elementi re-cached che non differiscano tra i siti come clientlibs, nonché dover impostare un agente di svuotamento della replica per ogni DocumentRoot configurato, aumentando la quantità di sovraccarico di svuotamento con ogni attivazione della pagina. Utilizza lo spazio dei nomi dei file e i relativi percorsi nella cache completa ed evita di utilizzare più DocumentRoots per i siti pubblicati.

File di configurazione

Dispatcher controlla ciò che è qualificato come "in cache" nella sezione /cache di qualsiasi file farm.
Nelle farm di configurazione della linea di base di AMS, troverai le nostre inclusioni come mostrato di seguito:

/cache {
    /rules {
        $include "/etc/httpd/conf.dispatcher.d/cache/ams_author_cache.any"
    }

Quando crei le regole per ciò che deve essere memorizzato in cache o meno, consulta la documentazione qui

Caching di Author

Abbiamo visto molte implementazioni in cui le persone non memorizzano in cache i contenuti di authoring.
Si stanno perdendo in un enorme miglioramento delle prestazioni e della reattività ai loro autori.

Parliamo della strategia adottata per configurare la farm di authoring in modo che venga memorizzata correttamente la cache.

Di seguito è riportata una sezione di base dell’autore /cache del nostro file farm di authoring:

/cache {
    /docroot "/mnt/var/www/author"
    /statfileslevel "2"
    /allowAuthorized "1"
    /rules {
        $include "/etc/httpd/conf.dispatcher.d/cache/ams_author_cache.any"
    }
    /invalidate {
        /0000 {
            /glob "*"
            /type "allow"
        }
    }
    /allowedClients {
        /0000 {
            /glob "*.*.*.*"
            /type "deny"
        }
        $include "/etc/httpd/conf.dispatcher.d/cache/ams_author_invalidate_allowed.any"
    }
}

Le cose importanti da notare sono che /docroot è impostato sulla directory della cache per l’autore.

Nota:

Assicurati che DocumentRoot nel file .vhost dell’autore corrisponda al parametro farm /docroot.

L’istruzione cache rules include il file /etc/httpd/conf.dispatcher.d/cache/ams_author_cache.any che contiene le seguenti regole:

/0000 {
 /glob "*"
 /type "deny"
}
/0001 {
 /glob "/libs/*"
 /type "allow"
}
/0002 {
 /glob "/libs/*.html"
 /type "deny"
}
/0003 {
 /glob "/libs/granite/csrf/token.json"
 /type "deny"
}
/0004 {
 /glob "/apps/*"
 /type "allow"
}
/0005 {
 /glob "/apps/*.html"
 /type "deny"
}
/0006 {
 /glob "/libs/cq/core/content/welcome.*"
 /type "deny"
}

In uno scenario di authoring, il contenuto cambia continuamente e di proposito. Desideri memorizzare nella cache solo gli elementi che non verranno modificati di frequente.
Abbiamo regole per memorizzare in cache /libs perché fanno parte dell’installazione AEM della linea di base e cambiano finché non hai installato un Service Pack, un Cumulative Fix Pack, un aggiornamento o un Hotfix. La memorizzazione in cache di questi elementi ha molto senso e offre vantaggi concreti all'esperienza di authoring degli utenti finali che utilizzano il sito.

Nota:

Tieni presente che anche queste regole memorizzano in cache /apps qui risiede il codice personalizzato dell’applicazione. Se stai sviluppando il codice in questa istanza, allora si dimostrerà molto confuso quando salvi il file e non vedi se si riflette nell'interfaccia utente a causa del fatto che serve una copia memorizzata nella cache. L’intenzione qui è che se esegui una distribuzione del codice in AEM, anche questa sarebbe poco frequente e parte dei passaggi di distribuzione dovrebbe consistere nel cancellare la cache di authoring. Anche in questo caso il vantaggio è enorme, rendendo il codice memorizzabile in cache più veloce per gli utenti finali.

ServeOnStale (o Serve su Stale/SOS)

Questa è una delle gemme di una funzione del dispatcher. Se l’editore è sotto carico o non risponde, in genere genera un codice di risposta http 502 o 503. Se ciò accade e questa funzione è abilitata, il dispatcher verrà istruito a distribuire comunque tutto il contenuto ancora nella cache nel miglior modo possibile, anche se non si tratta di una nuova copia. È meglio distribuire qualcosa, se disponibile, invece di mostrare solo un messaggio di errore che non offre alcuna funzionalità.

Nota:

Tieni presente che se il renderer del server di pubblicazione ha un timeout del socket o un messaggio di errore 500, questa funzione non verrà attivata. Se l'AEM è semplicemente irraggiungibile, questa funzione non fa nulla.

Questa impostazione può essere impostata su qualsiasi farm, ma è consigliabile applicarla solo ai file farm pubblicati. Di seguito è riportato un esempio di sintassi della funzione abilitata in un file farm:

/cache {
    /serveStaleOnError "1"

Memorizzazione in cache di pagine con parametri di query/argomenti

Nota:

Uno dei comportamenti normali del modulo Dispatcher è che se una richiesta ha un parametro di query nell’URI (in genere mostrato come /content/page.html)?myquery=value) salta la memorizzazione in cache del file e passa direttamente all’istanza AEM. Sta considerando questa richiesta come una pagina dinamica e non deve essere memorizzata in cache. Questo può causare un effetto negativo sull’efficienza della cache.

Se in AEM sono presenti pagine che accettano argomenti di GET/parametri di query nella riga dell’indirizzo che consentono il funzionamento della pagina ma non rendono diversi HTML, questi sono i candidati ideali per questo elemento di configurazione.

Puoi indicare al dispatcher quali argomenti ignorare e memorizzare ancora in cache la pagina.

Ad esempio, qualcuno ha creato un meccanismo di riferimento per i collegamenti profondi nei social media che utilizza il riferimento all’argomento nell’URI per sapere da dove proviene la persona.

Esempio:

https://www.retail.com/home.html?reference=android

https://www.retail.com/home.html?reference=facebook

La pagina è memorizzabile nella cache al 100% ma non la memorizza in cache perché gli argomenti sono presenti.
Per ovviare a questo problema, aggiungiamo la seguente sezione al file di configurazione farm:

/cache {
    /ignoreUrlParams {
        /0001 { /glob "*" /type "deny" }
        /0002 { /glob "reference" /type "allow" }
    }

Ora, quando il dispatcher vede la richiesta, ignora il fatto che la richiesta ha il parametro di query di riferimento e memorizza ancora nella cache la pagina.

Memorizzazione nella cache delle intestazioni di risposta

È abbastanza ovvio che Dispatcher memorizza in cache pagine .html e clientlibs, ma sapevi che può anche memorizzare in cache determinate intestazioni di risposta insieme al contenuto in un file con lo stesso nome ma con estensione .h? Questo consente di rispondere successivamente non solo al contenuto, ma anche alle intestazioni di risposta che devono accompagnarlo dalla cache.

L'AEM è in grado di gestire più della semplice codifica UTF-8.

A volte gli elementi hanno intestazioni speciali che aiutano a controllare i dettagli di codifica della cache TTL e le ultime marche temporali modificate.

Questi valori, quando vengono memorizzati in cache, vengono rimossi per impostazione predefinita e il server web apache httpd esegue il proprio lavoro di elaborazione della risorsa con i normali metodi di gestione dei file, normalmente limitati all’indovinazione del tipo mime in base alle estensioni dei file.

Se disponi della cache di Dispatcher per la risorsa e le intestazioni desiderate, puoi esporre l’esperienza corretta e assicurarti che tutti i dettagli la arrivino al browser dei client.

Ecco un esempio di farm con le intestazioni da memorizzare in cache specificate:

/cache {
 /headers {
  "Cache-Control"
  "Content-Disposition"
  "Content-Type"
  "Expires"
  "Last-Modified"
  "X-Content-Type-Options"
 }
}

Nell’esempio, hanno configurato l’AEM per distribuire le intestazioni che la rete CDN cerca per sapere quando annullare la validità della cache. Ciò significa che ora l’AEM può determinare correttamente quali file vengono invalidati in base alle intestazioni.

Nota:

Tieni presente che non puoi utilizzare espressioni regolari o la corrispondenza glob. È un elenco letterale delle intestazioni da memorizzare in cache. Inserisci solo un elenco delle intestazioni letterali da memorizzare in cache.

Invalida automaticamente periodo di tolleranza

Sui sistemi AEM con un’elevata attività da parte di autori che eseguono molte attivazioni di pagine, si può verificare una situazione di tipo "race condition" in cui si verificano ripetuti invalidamenti. Le richieste di scaricamento ripetute in modo pesante non sono necessarie e puoi introdurre una certa tolleranza per non ripetere uno scaricamento fino a quando il periodo di tolleranza non è trascorso.

Esempio di come funziona:

Se hai cinque richieste di invalidare /content/example/en/, tutte si verificano entro un periodo di 3 secondi.

Con questa funzione disattivata si invalida la directory della cache /content/example/en/ 5 volte.

Attivando questa funzione e impostandola su 5 secondi, la directory della cache verrebbe invalidata /content/exampleco/en/once.

Di seguito è riportato un esempio di sintassi di questa funzione configurata per un periodo di tolleranza di 5 secondi:

/cache {
    /gracePeriod "5"

Annullamento della validità basato su TTL

Una nuova funzione del modulo dispatcher era Durata (TTL) opzioni di annullamento della validità basate sugli elementi memorizzati in cache. Quando un elemento viene memorizzato nella cache, cerca la presenza di intestazioni di controllo cache e genera un file nella directory cache con lo stesso nome e un .ttl estensione.

Ecco un esempio della funzione configurata nel file di configurazione della farm:

/cache {
    /enableTTL "1"

Nota:

Tieni presente che l’AEM deve ancora essere configurato per inviare le intestazioni TTL in modo che il dispatcher possa rispettarle. L’attivazione di questa funzione consente solo al dispatcher di sapere quando rimuovere i file per i quali l’AEM ha inviato le intestazioni di controllo cache. Se l’AEM non inizia a inviare intestazioni TTL, dispatcher non farà nulla di speciale qui.

Regole filtro cache

Di seguito è riportato un esempio di configurazione di base per la quale gli elementi da memorizzare in cache su un editore:

/cache{
    /0000 {
        /glob "*"
        /type "allow"
    }
    /0001 {
        /glob "/libs/granite/csrf/token.json"
        /type "deny"
    }

Vogliamo rendere il nostro sito pubblicato il più greedy possibile e memorizzare tutto in cache.

Se esistono elementi che interrompono l’esperienza quando vengono memorizzati nella cache, puoi aggiungere regole per rimuovere l’opzione di memorizzare in cache tale elemento. Come vedi nell’esempio precedente, i token csrf non devono mai essere memorizzati in cache e sono stati esclusi. Ulteriori dettagli sulla stesura di queste regole sono disponibili sul sito qui.

In questa pagina