Informazioni sulla memorizzazione in cache delle directory

Descrizione

Ambiente
Adobe Experience Manager

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

Risoluzione

Directory di memorizzazione nella cache

Utilizziamo le seguenti directory di cache predefinite nelle installazioni della linea di base

• 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:

Manteniamo intenzionalmente il carico di lavoro pubblicato separato dal carico di lavoro dell’autore perché quando Apache cerca un file nel DocumentRoot, non sa da quale istanza AEM provenga. Pertanto, anche se la cache è disabilitata nella farm dell’autore, se DocumentRoot dell’autore è uguale a quello dell’editore, i file della cache verranno utilizzati quando sono presenti. Ciò significa che distribuirai i file dell’autore dalla cache pubblicata e offrirai ai visitatori un’esperienza di mix davvero straordinaria. Anche mantenere directory DocumentRoot separate per contenuti pubblicati diversi è una pessima idea. Sarà necessario creare più elementi nella cache che non differiscono tra siti come clientlibs, nonché impostare un agente di scaricamento della replica per ogni DocumentRoot configurato, aumentando la quantità di overhead di scaricamento con ogni attivazione della pagina. Utilizza lo spazio dei nomi dei file e i percorsi completi in cache ed evita più DocumentRoots per i siti pubblicati.

File di configurazione

Il Dispatcher controlla ciò che si qualifica come memorizzabile in cache nella sezione /cache di qualsiasi file farm.
Nelle farm di configurazione della linea di base AMS, troverai i nostri "include" come mostrato di seguito:

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

Quando crei le regole per cosa memorizzare in cache o meno, fai riferimento alla documentazione qui

Creazione di cache

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

Discutiamo la strategia adottata per configurare la farm degli autori in modo che venga memorizzata correttamente nella cache.

Ecco una sezione dell’autore di base /cache del file farm dell’autore:

/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 qui sono che /docroot è impostato sulla directory cache per l’autore.

Nota:

Assicurati che DocumentRoot nel file .vhost dell'autore corrisponda al parametro farms /docroot.

L’istruzione "include" delle regole di cache 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 frequentemente.
Abbiamo regole per memorizzare in cache /libs perché fanno parte dell'installazione della linea di base AEM e cambierebbe finché non avrai installato un Service Pack, Cumulative Fix Pack, Upgrade o Hotfix. La memorizzazione in cache di questi elementi ha un senso e apporta vantaggi reali all’esperienza di authoring degli utenti finali che utilizzano il sito.

Nota:

Tieni presente che anche queste regole memorizzano nella cache /apps è qui che vive il codice dell'applicazione personalizzata. Se stai sviluppando il codice su questa istanza, allora si rivelerà molto confuso quando salvi il file e non vedere se si riflette nell'interfaccia utente a causa del fatto che serve una copia in cache. In questo caso, se distribuisci il codice in AEM, anche questo non è frequente e parte dei passaggi di distribuzione dovrebbe essere quello di cancellare la cache dell’autore. Anche in questo caso il vantaggio è enorme, rendendo il codice memorizzabile nella cache più veloce per gli utenti finali.

ServeOnStale (Servizio AKA su Stale / SOS)

Questa è una delle gemme di una caratteristica del dispatcher. Se l'editore è sotto carico o non risponde, in genere genera un codice di risposta http 502 o 503. Se questo accade e questa funzione è abilitata, il dispatcher sarà istruito a continuare a servire qualsiasi contenuto ancora presente nella cache come miglior tentativo, anche se non è una nuova copia. È meglio servire qualcosa se ce l'hai invece di mostrare un messaggio di errore che non offre funzionalità.

Nota:

Tieni presente che se il renderer dell’editore ha un timeout del socket o un messaggio di errore 500, questa funzione non si attiverà. Se AEM non è raggiungibile, questa funzione non funziona.

Questa impostazione può essere impostata su qualsiasi farm, ma è utile applicarla solo ai file farm pubblicati. Ecco 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 (generalmente mostrato come /content/page.html?myquery=value) salterà la memorizzazione in cache del file e andrà direttamente all'istanza AEM. Considera questa richiesta come una pagina dinamica e non deve essere memorizzata nella cache. Questo può causare un effetto negativo sull’efficienza della cache.

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

Puoi dire al dispatcher quali argomenti ignorare e comunque memorizzare la pagina nella cache.

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

Esempio di utilizzo:

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 memorizza in cache perché gli argomenti sono presenti.
Per ovviare a questo problema, aggiungiamo la seguente sezione al file di configurazione della farm:

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

Ora, quando il dispatcher visualizza la richiesta, ignorerà il fatto che la richiesta ha il parametro di query di riferimento e memorizza comunque nella cache la pagina.

Memorizzazione in cache delle intestazioni di risposta

È piuttosto ovvio che il dispatcher memorizza in cache le pagine .html e clientlibs, ma sapevi che può anche memorizzare in cache particolari intestazioni di risposta accanto al contenuto in un file con lo stesso nome ma con estensione file .h? Questo consente la risposta successiva non solo al contenuto, ma anche alle intestazioni di risposta che dovrebbero accompagnarlo dalla cache.

AEM gestire più di una semplice codifica UTF-8.

A volte gli elementi hanno intestazioni speciali che aiutano a controllare i dettagli di codifica del TTL della cache e gli ultimi timestamp modificati.

Questi valori, quando vengono memorizzati nella cache, sono spogliati per impostazione predefinita e il server web apache httpd eseguirà il proprio lavoro di elaborazione della risorsa con i suoi normali metodi di gestione dei file, che normalmente si limitano all’indovinazione dei tipi mime in base alle estensioni dei file.

Se disponi della cache del dispatcher per la risorsa e le intestazioni desiderate, puoi esporre l’esperienza corretta e accertarti che tutti i dettagli siano indirizzati al browser dei client.

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

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

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

Nota:

Tieni presente che non puoi utilizzare espressioni regolari o corrispondenze globali. È una lista letterale delle intestazioni da memorizzare in cache. Inserisci solo un elenco delle intestazioni letterali che desideri memorizzare in cache.

Periodo di tolleranza per annullamento automatico validità

Nei sistemi AEM che svolgono molte attività da parte degli autori che eseguono molte attivazioni di pagina, si può verificare una race condition in cui si verificano ripetuti invalidamenti. Le richieste di scaricamento ripetute in modo significativo non sono necessarie e puoi generare una certa tolleranza per non ripetere uno scaricamento finché il periodo di tolleranza non viene cancellato.

Esempio di funzionamento:

Se hai cinque richieste per annullare la validità di /content/exampleco/en/, tutto avviene entro un periodo di 3 secondi.

Con questa funzione, invalideresti la directory della cache /content/exampleco/en/ 5 volte.

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

Ecco un esempio di sintassi di questa funzione configurata per un periodo di tolleranza di 5 secondi:

/cache {
    /gracePeriod "5"

Invalidazione basata su TTL

Una nuova funzionalità del modulo dispatcher era Time to Live (TTL) opzioni di invalidazione basate per gli elementi memorizzati nella cache. Quando un elemento viene memorizzato nella cache, cerca la presenza di intestazioni di controllo della cache e genera un file nella directory della 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 AEM deve ancora essere configurato per inviare intestazioni TTL per il dispatcher per rispettarle. L’attivazione di questa funzione consente solo al dispatcher di sapere quando rimuovere i file per i quali AEM inviato intestazioni di controllo cache. Se AEM non inizia a inviare intestazioni TTL, il dispatcher non farà nulla di speciale qui.

Regole filtro cache

Ecco un esempio di configurazione della linea di base per cui gli elementi devono essere memorizzati nella cache su un editore:

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

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

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

Risorse Business.Adobe.com