Introduzione intro

Il traffico passa attraverso la rete CDN a un livello di server web Apache, che supporta moduli tra cui Dispatcher. Per migliorare le prestazioni, Dispatcher viene utilizzato principalmente come cache per limitare l’elaborazione sui nodi di pubblicazione.
È possibile applicare delle regole alla configurazione di Dispatcher per modificare eventuali impostazioni di scadenza predefinite della cache, con conseguente memorizzazione nella cache della rete CDN. Dispatcher rispetta anche le intestazioni di scadenza della cache risultanti se enableTTL è abilitato nella configurazione di Dispatcher, il che significa che aggiorna contenuti specifici anche al di fuori di quelli ripubblicati.

Questa pagina descrive anche come viene invalidata la cache di Dispatcher e come funziona il caching a livello di browser per quanto riguarda le librerie lato client.

Memorizzazione in cache caching

HTML/Text html-text

Define DISABLE_DEFAULT_CACHING

Questo metodo è utile, ad esempio, quando la logica di business richiede l’ottimizzazione dell’intestazione age (con un valore basato sul giorno del calendario) perché per impostazione predefinita l’intestazione age è impostata su 0. Detto questo, prestare attenzione quando si disattiva il caching predefinito.

Librerie lato client (js,css) client-side-libraries

Immagini e qualsiasi contenuto di dimensioni sufficienti per essere archiviato nell'archivio BLOB images

Il comportamento predefinito per i programmi creati dopo metà maggio 2022 (in particolare, per gli ID programma superiori a 65000) consiste nella memorizzazione in cache per impostazione predefinita, nel rispetto anche del contesto di autenticazione della richiesta. I programmi meno recenti (ID di programma uguali o inferiori a 65000) non memorizzano in cache il contenuto BLOB per impostazione predefinita.

In entrambi i casi, le intestazioni di memorizzazione in cache possono essere ignorate su un livello a grana più fine a livello di Apache/Dispatcher utilizzando Apache mod_headers direttive, ad esempio:

   <LocationMatch "^/content/.*\.(jpeg|jpg)$">
     Header set Cache-Control "max-age=222"
     Header set Age 0
   </LocationMatch>

Quando modifichi le intestazioni di memorizzazione in cache a livello di Dispatcher, presta attenzione a non creare una cache troppo ampia. Consulta la discussione nella sezione HTML/testo sopra. Inoltre, assicurati che le risorse destinate a essere mantenute private (anziché memorizzate in cache) non facciano parte del LocationMatch filtri direttiva.

Le risorse JCR (più grandi di 16 KB) memorizzate nell’archivio BLOB vengono solitamente servite come reindirizzamenti 302 dall’AEM. Questi reindirizzamenti vengono intercettati e seguiti da CDN e il contenuto viene distribuito direttamente dall’archivio BLOB. Su queste risposte è possibile personalizzare solo un set limitato di intestazioni. Ad esempio, per personalizzare Content-Disposition utilizza le direttive dispatcher nel modo seguente:

<LocationMatch "\.(?i:pdf)$">
  ForceType application/pdf
  Header set Content-Disposition inline
  </LocationMatch>

L’elenco delle intestazioni che possono essere personalizzate nelle risposte BLOB è:

content-security-policy
x-frame-options
x-xss-protection
x-content-type-options
x-robots-tag
access-control-allow-origin
content-disposition
permissions-policy
referrer-policy
x-vhost
content-disposition
cache-control
vary

Nuovo comportamento di caching predefinito new-caching-behavior

Il livello AEM imposta le intestazioni della cache a seconda che l’intestazione della cache sia già stata impostata e il valore del tipo di richiesta. Se non è impostata alcuna intestazione di controllo della cache, il contenuto pubblico viene memorizzato nella cache e il traffico autenticato viene impostato su privato. Se è impostata un’intestazione di controllo cache, le intestazioni della cache vengono lasciate intatte.

Sebbene non sia consigliato, è possibile modificare il nuovo comportamento predefinito in modo che segua il comportamento precedente (ID programma uguali o inferiori a 65000) impostando la variabile di ambiente Cloud Manager AEM_BLOB_ENABLE_CACHING_HEADERS su false.

Comportamento di memorizzazione nella cache predefinito precedente old-caching-behavior

Per impostazione predefinita, il livello AEM non memorizza in cache il contenuto BLOB.

Ora, le immagini nell’archiviazione BLOB contrassegnate come private non possono essere memorizzate nella cache in Dispatcher utilizzando Memorizzazione in cache sensibile alle autorizzazioni. L’immagine viene sempre richiesta all’origine dell’AEM e trasmessa se l’utente è autorizzato.

Altri tipi di file di contenuto nell’archivio nodi other-content

Ulteriori ottimizzazioni further-optimizations

Analisi del rapporto di hit della cache CDN analyze-chr

Consulta la tutorial sull’analisi del rapporto di hit nella cache per informazioni sul download dei registri CDN e sull’analisi del rapporto tra i caratteri della cache del sito, utilizza una dashboard.

Comportamento richiesta HEAD request-behavior

Quando viene ricevuta una richiesta HEAD al CDN di Adobe per una risorsa che è non memorizzata nella cache, la richiesta viene trasformata e ricevuta dall’istanza di Dispatcher e/o AEM come richiesta di GET. Se la risposta è memorizzabile in cache, le richieste HEAD successive vengono servite dalla rete CDN. Se la risposta non è memorizzabile in cache, le richieste HEAD successive vengono passate al Dispatcher, all’istanza AEM o a entrambi, per un periodo di tempo che dipende da Cache-Control TTL.

Parametri della campagna di marketing marketing-parameters

Gli URL del sito web includono spesso parametri della campagna di marketing utilizzati per monitorare il successo di una campagna.

Per gli ambienti creati a ottobre 2023 o versioni successive, per memorizzare in cache meglio le richieste, la rete CDN rimuoverà i parametri di query comuni relativi al marketing, in particolare quelli che corrispondono al seguente pattern regex:

^(utm_.*|gclid|gdftrk|_ga|mc_.*|trk_.*|dm_i|_ke|sc_.*|fbclid)$

Invia un ticket di supporto se desideri disabilitare questo comportamento.

Per gli ambienti creati prima di ottobre 2023, si consiglia di configurare i ignoreUrlParams proprietà come documentato qui.

Esistono due possibilità per ignorare i parametri di marketing. (dove il primo è preferito per ignorare il busting della cache tramite parametri di query):

/ignoreUrlParams {
   /0001 { /glob "*" /type "allow" }
   /0002 { /glob "page" /type "deny" }
   /0003 { /glob "product" /type "deny" }
}

/ignoreUrlParams {
   /0001 { /glob "*" /type "deny" }
   $include "../cache/marketing_query_parameters.any"
}

Annullamento della validità della cache di Dispatcher disp

In generale, non è necessario invalidare la cache di Dispatcher. Al contrario, quando il contenuto viene ripubblicato e la rete CDN rispetta le intestazioni di scadenza della cache, dovrai fare affidamento sull’aggiornamento della cache da parte di Dispatcher.

Annullamento della validità della cache del Dispatcher durante l’attivazione/disattivazione cache-activation-deactivation

Come per le versioni precedenti dell’AEM, la pubblicazione o l’annullamento della pubblicazione di pagine cancella il contenuto dalla cache di Dispatcher. Se si sospetta un problema di caching, è necessario ripubblicare le pagine in questione e assicurarsi che sia disponibile un host virtuale che corrisponda al ServerAlias localhost, richiesto per l’annullamento della validità della cache di Dispatcher.

Quando l’istanza Publish riceve una nuova versione di una pagina o di una risorsa dall’autore, utilizza l’agente di svuotamento per invalidare i percorsi appropriati nel proprio Dispatcher. Il percorso aggiornato viene rimosso dalla cache di Dispatcher, insieme ai relativi elementi principali, fino a un livello (puoi configurare questo livello con statfileslevel).

Annullamento esplicito della validità della cache di Dispatcher explicit-invalidation

L’Adobe consiglia di fare affidamento sulle intestazioni di cache standard per controllare il ciclo di vita della distribuzione dei contenuti. Tuttavia, se necessario, è possibile annullare la validità del contenuto direttamente in Dispatcher.

L’elenco seguente contiene scenari in cui potresti voler invalidare esplicitamente la cache (mentre facoltativamente stai in ascolto del completamento dell’invalidazione):

Esistono due approcci per invalidare esplicitamente la cache:

Gli approcci sono diversi in termini di disponibilità dei livelli, possibilità di deduplicare gli eventi e garanzia di elaborazione degli eventi. La tabella seguente riassume queste opzioni:

Le due azioni direttamente correlate all’invalidamento della cache sono Invalidate API SCD (Sling Content Distribution) e Deactivate API della replica.

Inoltre, dalla tabella, puoi osservare che:

In conclusione, se desideri annullare la validità della cache di Dispatcher, l’opzione consigliata è quella di utilizzare l’azione Invalida API SCD di Author. Inoltre, puoi anche ascoltare l’evento in modo da poter quindi attivare ulteriori azioni a valle.

Distribuzione dei contenuti Sling (SCD) sling-distribution

Quando utilizzi l’azione SCD di Author, il modello di implementazione è il seguente:

@Reference
private Distributor distributor;

ResourceResolver resolver = ...; // the resource resolver used for authorizing the request
String agentName = "publish";    // the name of the agent used to distribute the request

String pathToInvalidate = "/content/to/invalidate";
DistributionRequest distributionRequest = new SimpleDistributionRequest(DistributionRequestType.INVALIDATE, false, pathToInvalidate);
distributor.distribute(agentName, resolver, distributionRequest);

package org.apache.sling.distribution.journal.shared;

import org.apache.sling.discovery.DiscoveryService;
import org.apache.sling.distribution.journal.impl.event.DistributionEvent;
import org.osgi.service.component.annotations.Component;
import org.osgi.service.component.annotations.Reference;
import org.osgi.service.event.Event;
import org.osgi.service.event.EventHandler;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import static org.apache.sling.distribution.DistributionRequestType.INVALIDATE;
import static org.apache.sling.distribution.event.DistributionEventProperties.DISTRIBUTION_PATHS;
import static org.apache.sling.distribution.event.DistributionEventProperties.DISTRIBUTION_TYPE;
import static org.apache.sling.distribution.event.DistributionEventTopics.AGENT_PACKAGE_DISTRIBUTED;
import static org.osgi.service.event.EventConstants.EVENT_TOPIC;

@Component(immediate = true, service = EventHandler.class, property = {
        EVENT_TOPIC + "=" + AGENT_PACKAGE_DISTRIBUTED
})
public class InvalidatedHandler implements EventHandler {
    private static final Logger LOG = LoggerFactory.getLogger(InvalidatedHandler.class);

    @Reference
    private DiscoveryService discoveryService;

    @Override
    public void handleEvent(Event event) {

        String distributionType = (String) event.getProperty(DISTRIBUTION_TYPE);

        if (INVALIDATE.name().equals(distributionType)) {
            boolean isLeader = discoveryService.getTopology().getLocalInstance().isLeader();
            // process the OSGi event on the leader author instance
            if (isLeader) {
                String[] paths = (String[]) event.getProperty(DISTRIBUTION_PATHS);
                String packageId = (String) event.getProperty(DistributionEvent.PACKAGE_ID);
                invalidated(paths, packageId);
            }
        }
    }

    private void invalidated(String[] paths, String packageId) {
        // custom logic
        LOG.info("Successfully applied package with id {}, paths {}", packageId, paths);
    }
}

API di replica replication-api

Di seguito è riportato il modello di implementazione per l’utilizzo dell’azione di disattivazione dell’API di replica:

L’endpoint dell’agente di svuotamento non è configurabile, ma è preconfigurato per puntare a Dispatcher e corrisponde al servizio di pubblicazione in esecuzione insieme all’agente di svuotamento.

L’agente di svuotamento può in genere essere attivato da codice personalizzato basato su eventi o flussi di lavoro OSGi.

String[] paths = …
ReplicationOptions options = new ReplicationOptions();
options.setSynchronous(true);
options.setFilter( new AgentFilter {
  public boolean isIncluded (Agent agent) {
   return agent.getId().equals("flush");
  }
});

Replicator.replicate (session,ReplicationActionType.DELETE,paths, options);

Librerie lato client e coerenza delle versioni content-consistency

Le pagine sono composte da HTML, JavaScript, CSS e immagini. I clienti sono incoraggiati a utilizzare 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 la gestione automatica delle versioni. Ciò significa che gli sviluppatori possono archiviare le modifiche alle librerie JS nel controllo del codice sorgente e che l’ultima versione è disponibile quando un cliente invia la propria versione. Senza questo flusso di lavoro, gli sviluppatori devono modificare manualmente HTML con riferimenti alla nuova versione della libreria, il che è particolarmente oneroso se la stessa libreria condivide molti modelli di HTML.

Quando vengono rilasciate in produzione le nuove versioni delle librerie, le pagine HTML di riferimento vengono aggiornate con nuovi collegamenti alle versioni aggiornate della libreria. Dopo la scadenza della cache del browser per una determinata pagina HTML, non c’è alcun problema che le vecchie librerie vengano caricate dalla cache del browser. Il motivo è che ora è garantito che la pagina aggiornata (da AEM) faccia riferimento alle nuove versioni delle librerie. In altre parole, una pagina HTML aggiornata include tutte le versioni più recenti della libreria.

Il meccanismo alla base di questa funzionalità è un hash serializzato, che viene aggiunto al collegamento della libreria client. Garantisce un URL univoco con versione affinché il browser possa memorizzare in cache i file CSS/JS. L’hash serializzato viene aggiornato solo quando cambia il contenuto della libreria client. Ciò significa che se si verificano aggiornamenti non correlati (ovvero, nessuna modifica ai css/js sottostanti della libreria client) anche con una nuova distribuzione, il riferimento rimane lo stesso. A sua volta, assicura meno interruzioni alla cache del browser.

Abilitazione delle versioni Longcache delle librerie lato client: QuickStart per SDK as a Cloud Service per AEM enabling-longcache

Le inclusioni clientlib predefinite in una pagina HTML hanno un aspetto simile al seguente:

<link rel="stylesheet" href="/etc.clientlibs/wkndapp/clientlibs/clientlib-base.css" type="text/css">

Quando è abilitato il controllo rigoroso delle versioni di clientlib, viene aggiunta una chiave hash a lungo termine come selettore alla libreria client. Di conseguenza, il riferimento clientlib è simile al seguente:

<link rel="stylesheet" href="/etc.clientlibs/wkndapp/clientlibs/clientlib-base.lc-7c8c5d228445ff48ab49a8e3c865c562-lc.css" type="text/css">

Il controllo delle versioni rigorose di clientlib è abilitato per impostazione predefinita in tutti gli ambienti AEM as a Cloud Service.

Per abilitare il controllo rigoroso delle versioni clientlib nel Quickstart dell’SDK locale, effettua le seguenti operazioni: