Inleiding intro

Het verkeer gaat door CDN tot een Apache laag van de Webserver over, die modules met inbegrip van Dispatcher steunt. Om de prestaties te verbeteren, wordt Dispatcher vooral gebruikt als cache om de verwerking op de publicatieknooppunten te beperken.
De regels kunnen op de configuratie van Dispatcher worden toegepast om het even welke montages van de standaardgeheim voorgeheugenvervalsing te wijzigen, resulterend in caching bij CDN. Dispatcher respecteert ook de resulterende headers voor het verlopen van de cache als enableTTL is ingeschakeld in de Dispatcher-configuratie, wat betekent dat specifieke inhoud wordt vernieuwd, zelfs buiten de inhoud die opnieuw wordt gepubliceerd.

Op deze pagina wordt ook beschreven hoe de Dispatcher-cache ongeldig wordt gemaakt en hoe caching werkt op browserniveau met betrekking tot client-side bibliotheken.

Caching caching

HTML/Tekst html-text

Define DISABLE_DEFAULT_CACHING

Deze methode is bijvoorbeeld handig wanneer uw bedrijfslogica een nauwkeurige afstemming van de paginakoptekst vereist (met een waarde die op kalenderdag is gebaseerd), omdat de paginakoptekst standaard op 0 is ingesteld. Dat gezegd, oefening voorzichtigheid wanneer het uitzetten van gebrek caching.

Client-Side bibliotheken (js,css) client-side-libraries

Afbeeldingen en inhoud die groot genoeg is om in blokopslag te worden opgeslagen images

Het standaardgedrag voor programma's die na medio mei 2022 worden gemaakt (met name voor programma-id's van meer dan 65000), is standaard in cache plaatsen, terwijl ook de verificatiecontext van het verzoek wordt gerespecteerd. Oudere programma's (programma-id's van 65000 of lager) plaatsen standaard geen blob-inhoud in de cache.

In beide gevallen kunnen de headers in de cache op een fijner korrelig niveau op de Apache/Dispatcher-laag worden overschreven met behulp van de Apache mod_headers -instructies, bijvoorbeeld:

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

Wanneer het wijzigen van de caching kopballen bij de laag van Dispatcher, ben voorzichtig om niet te wijd in het voorgeheugen onder te brengen. Zie de bespreking in de HTML/tekstsectie hierboven. Zorg er ook voor dat elementen die bedoeld zijn om privé te blijven (in plaats van in cache te worden geplaatst) geen deel uitmaken van de richtingsfilters van LocationMatch .

De middelen JCR (groter dan 16KB) die in blob opslag worden opgeslagen worden typisch gediend als 302 omleidingen door AEM. Deze omleidingen worden onderschept en door CDN gevolgd en de inhoud wordt direct geleverd van de blob opslag. Op deze reacties kan slechts een beperkte set kopteksten worden aangepast. Als u bijvoorbeeld Content-Disposition wilt aanpassen, moet u de verzendinstructies als volgt gebruiken:

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

De lijst van kopballen die op blob reacties kunnen worden aangepast zijn:

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

Nieuw standaardgedrag in cache new-caching-behavior

De AEM laag plaatst geheim voorgeheugenkopballen afhankelijk van of de geheim voorgeheugenkopbal reeds is geplaatst en de waarde van het verzoektype. Als geen kopbal van de geheim voorgeheugencontrole wordt geplaatst, wordt de openbare inhoud caching, en voor authentiek verklaard verkeer geplaatst aan privé. Als een kopbal van de geheim voorgeheugencontrole wordt geplaatst, worden de geheim voorgeheugenkopballen verlaten onveranderd.

Hoewel dit niet wordt aanbevolen, is het mogelijk om het nieuwe standaardgedrag te wijzigen om het oude gedrag te volgen (programma-id's gelijk aan of lager dan 65000) door de Cloud Manager-omgevingsvariabele AEM_BLOB_ENABLE_CACHING_HEADERS in te stellen op false.

Oudere standaardcaching, gedrag old-caching-behavior

In de AEM-laag wordt blob-inhoud niet standaard in de cache opgeslagen.

Nu, kunnen de beelden in blob opslag die duidelijk privé zijn niet in het voorgeheugen ondergebracht bij Dispatcher gebruikend Gevoelige Caching van de Toestemming. De afbeelding wordt altijd opgevraagd bij de AEM oorsprong en wordt weergegeven als de gebruiker geautoriseerd is.

Andere inhoudstypen in nodenarchief other-content

Verdere optimalisaties further-optimizations

Hit-verhouding CDN-cache analyseren analyze-chr

Zie de zelfstudie van de de verhoudingsanalyse van de geheim voorgeheugentreffelijkheidvoor informatie over het downloaden van CDN- logboeken en het analyseren van de het geheime voorgeheugenbreedteverhouding van uw plaats, gebruikend een dashboard.

HEAD-aanvraaggedrag request-behavior

Wanneer een verzoek van de HEAD bij de Adobe CDN voor een middel wordt ontvangen dat ​ ​niet {in het voorgeheugen ondergebracht is, wordt het verzoek getransformeerd en door Dispatcher en/of AEM instantie als GET- verzoek ontvangen. Als de reactie cacheable is, dan worden de verdere verzoeken van HEAD van CDN gediend. Als de reactie niet cacheable is, dan worden de verdere verzoeken van HEAD overgegaan tot de Dispatcher, of AEM instantie, of allebei, voor een tijd die van Cache-Control TTL afhangt.

Parameters van de marketingcampagne marketing-parameters

URL's van websites bevatten vaak parameters voor marketingcampagnes die worden gebruikt om het succes van een campagne te volgen.

Voor milieu's die in Oktober 2023 of recenter worden gecreeerd, aan betere geheim voorgeheugenverzoeken, zal CDN gemeenschappelijke marketing verwante vraagparameters, specifiek die verwijderen die het volgende regex patroon aanpassen:

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

Deze functionaliteit kan worden van een knevel voorzien en van het gebruiken van a requestTransformations vlag in CDN configuratie.

Als u bijvoorbeeld wilt ophouden met het verwijderen van marketingparams op CDN-niveau, moet u removeMarketingParams: false implementeren met een config die de volgende sectie bevat.

kind: "CDN"
version: "1"
metadata:
  envTypes: ["dev", "stage", "prod"]
data:
  requestTransformations:
    removeMarketingParams: false

In het geval dat removeMarketingParams de functionaliteit op CDN niveau wordt onbruikbaar gemaakt wordt het nog geadviseerd om het 1} bezit van de configuratie van Dispatcher te vormen {; zie Vormend Dispatcher - het Negeren van Parameters URL.ignoreUrlParams

Er zijn twee mogelijkheden om marketingparameters te negeren. (Waar de eerste voorkeur cachebusting via queryparameters negeert):

/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"
}

Dispatcher Cache-validatie disp

Over het algemeen is het niet nodig om de Dispatcher cache ongeldig te maken. In plaats daarvan moet u erop vertrouwen dat de Dispatcher de cache vernieuwt wanneer inhoud opnieuw wordt gepubliceerd en dat de CDN de headers voor het verlopen van de cache respecteert.

Dispatcher Cache-validatie tijdens activering/deactivering cache-activation-deactivation

Net als bij eerdere versies van AEM worden door het publiceren of verwijderen van pagina's de inhoud uit de Dispatcher-cache gewist. Als een cacheprobleem wordt vermoed, moet u de pagina's in kwestie opnieuw publiceren en zorgen dat er een virtuele host beschikbaar is die overeenkomt met de localhost van ServerAlias , die vereist is voor ongeldigverklaring van het Dispatcher-cachegeheugen.

Wanneer de publicatieinstantie een nieuwe versie van een pagina of element van de auteur ontvangt, gebruikt deze de agent flush om de juiste paden op de Dispatcher ongeldig te maken. De bijgewerkte weg wordt verwijderd uit het geheime voorgeheugen van Dispatcher, samen met zijn ouders, tot een niveau (u kunt dit niveau met statfileslevelvormen).

Expliciete ongeldigmaking van de Dispatcher-cache explicit-invalidation

Adobe raadt aan dat u de levenscyclus van de levering van inhoud beheert met behulp van standaard cacheheaders. Indien nodig is het echter mogelijk inhoud rechtstreeks in Dispatcher ongeldig te maken.

De volgende lijst bevat scenario's waar u uitdrukkelijk het geheime voorgeheugen zou kunnen willen invalideren (terwijl naar keuze het luisteren naar de voltooiing van de ongeldigverklaring):

Er zijn twee benaderingen om het geheime voorgeheugen uitdrukkelijk ongeldig te maken:

De benaderingen verschillen in termen van laagbeschikbaarheid, de capaciteit om gebeurtenissen en gebeurtenisverwerkingsgarantie te dedupliceren. De onderstaande tabel geeft een overzicht van de volgende opties:

De twee acties die rechtstreeks verband houden met cachevalidatie zijn Sling Content Distribution (SCD) API Invalidate and Replication API Deactivate.

Uit de tabel kunt u ook het volgende optekenen:

Als u het Dispatcher-cachegeheugen wilt invalideren, kunt u het beste de handeling voor invalidatie van de SCD API van de auteur gebruiken. U kunt ook luisteren naar de gebeurtenis, zodat u vervolgens verdere downstreamacties kunt activeren.

Verdelen van inhoud (SCD) sling-distribution

Bij gebruik van de SCD-actie van Auteur ziet het implementatiepatroon er als volgt uit:

@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);
    }
}

Replicatie-API replication-api

Hieronder ziet u het implementatiepatroon bij gebruik van de API-deactivering voor replicatie:

Het uitlijnende agenteneindpunt is niet configureerbaar maar eerder preconfigured om aan Dispatcher te richten, die met de publicatieservice wordt aangepast die naast de uitlijningsagent loopt.

De spoelagent kan typisch door douanecode worden teweeggebracht die op gebeurtenissen OSGi of werkschema's wordt gebaseerd.

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);

Client-Side bibliotheken en consistentie van versies content-consistency

Pagina's bestaan uit HTML, JavaScript, CSS en afbeeldingen. De klanten worden aangemoedigd om het cliënt-KantBibliotheken (clientlibs) kaderte gebruiken om JavaScript en CSS middelen in HTML pagina's in te voeren, rekenend voor gebiedsdelen tussen bibliotheken JS.

Het clientlibs-framework biedt automatisch versiebeheer. Dit houdt in dat ontwikkelaars wijzigingen in JS-bibliotheken in broncontrole kunnen inchecken en dat de nieuwste versie beschikbaar wordt gesteld wanneer een klant zijn release onder druk zet. Zonder deze workflow moeten ontwikkelaars HTML handmatig wijzigen met verwijzingen naar de nieuwe versie van de bibliotheek. Dit is vooral lastig als dezelfde bibliotheek veel HTML-sjablonen deelt.

Wanneer de nieuwe versies van bibliotheken worden vrijgegeven voor productie, worden de HTML-pagina's waarnaar wordt verwezen, bijgewerkt met nieuwe koppelingen naar die bijgewerkte bibliotheekversies. Nadat de browsercache voor een bepaalde HTML-pagina is verlopen, is er geen bezorgdheid dat de oude bibliotheken vanuit de browsercache worden geladen. De reden hiervoor is dat de vernieuwde pagina (van AEM) nu gegarandeerd verwijst naar de nieuwe versies van de bibliotheken. Een vernieuwde HTML-pagina bevat dus alle meest recente bibliotheekversies.

Het mechanisme achter deze mogelijkheid is een geserialiseerde hash, die aan de verbinding van de cliëntbibliotheek wordt toegevoegd. Hiermee wordt een unieke, versiegekoppelde URL voor de browser gegarandeerd die de CSS/JS in cache plaatst. De geserialiseerde hash wordt alleen bijgewerkt wanneer de inhoud van de clientbibliotheek wordt gewijzigd. Dit houdt in dat als er niet-gerelateerde updates optreden (dat wil zeggen dat er geen wijzigingen zijn aangebracht in de onderliggende css/js van de clientbibliotheek) zelfs met een nieuwe implementatie, de verwijzing ongewijzigd blijft. Hierdoor wordt de browsercache minder verstoord.

Longcache-versies van Client-Side Libraries inschakelen - AEM as a Cloud Service SDK Quickstart enabling-longcache

De standaard clientlib omvat op een pagina van HTML kijkt als het volgende voorbeeld:

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

Wanneer strikte clientlib-versioning is ingeschakeld, wordt een lange-termijnhash-toets toegevoegd als kiezer aan de clientbibliotheek. Dientengevolge, ziet de cliëntlib verwijzing als dit:

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

Strikte clientlib-versioning is standaard ingeschakeld in alle AEM as a Cloud Service-omgeving.

Ga als volgt te werk om strikte clientlib-versioning in te schakelen in de lokale SDK Quickstart: