Dokumentation

Hur optimerar jag Dispatcher-cachen?

Last update: Tue Jun 18 2024 00:00:00 GMT+0000 (Coordinated Universal Time)

I den här artikeln finns detaljerade anvisningar om de olika sätten att optimera Dispatcher-cachen. Den beskriver vidare stegen för att aktivera invalidationer av TTL-format ("Time to Live" eller utgångsdatum), inaktivera Dispatcher flush-agenter och återhämta Dispatcher flush, bland annat.

Beskrivning description

Miljö

Adobe Experience Manager

Problem/symtom

Den här artikeln fokuserar på de senaste optimeringarna i AEM Dispatcher och hur du bäst utnyttjar dem. AEM Dispatcher är en cachelagring omvänd proxy server som är avsedd att användas med Adobe Experience Manager. Den kan installeras och köras som en modul i ett befintligt webbserverprogram. När den här artikeln skrivs är Dispatcher Module stöds på Apache HTTP Server, Microsoft IIS och iPlanet.

Upplösning resolution

Hur fungerar Dispatcher-cachning?

På den mest grundläggande nivån är AEM dispatcher en omvänd proxy som fungerar genom att utföra cachelagring, tömning av cache och cacheogiltigförklaring.

Mer information om Dispatcher finns i de relaterade länkarna:

  1. Så här fungerar Dispatcher och hur du installerar den.
  2. Konfigurationsalternativ finns i Dispatcher.
  3. Webbinarium om hur Dispatcher fungerar - Observera att viss information i presentationen baseras på äldre versioner av dispatchern.
  4. Gems webbinariesession om Dispatcher-funktioner, CDN-användning och -säkerhet.
  5. Gems-session om nyare funktioner i Dispatcher (efter v4.1.9).

Optimera Dispatcher-cachen

Här är några sätt att optimera Dispatcher-cachen:

  1. Cachelagra nästan allt  - Det innebär att allt innehåll som användarna begär mer än en gång cachelagras.

  2. Cachelagra anpassat innehåll under olika tidsperioder  - Om din webbplats har personaliserat innehåll bör du överväga att använda Apache Sling Dynamic Includes i ditt AEM program för att utnyttja Ajax (asynkrona JavaScript- och XML-anrop på webbläsarnivå), SSI (Server Side Includes på webbservernivå) och ESI (Edge-side Includes på CDN-nivå) för att cachelagra olika delar av sidan under olika tidsperioder.

  3. Ta aldrig bort Dispatcher-cachen på en livedatabaserare  - Om en Dispatcher hanterar livematerial och du tar bort cachen, leder det till en enorm mängd förfrågningar som skickas tillbaka till AEM.  På grund av detta bör Dispatcher-cachen aldrig tas bort på en livedatabaserare.

  4. Använd cachen  - Innan du tar bort Dispatcher-cachen drar du ut Dispatcher från belastningsutjämnaren, tar bort cachen och kör sedan ett webbcrawlningsverktyg för att cachelagra filer på Dispatcher innan du placerar den på belastningsutjämnaren.

  5. Cachelagra felsidor  - utnyttja DispatcherPassError 1 (specifikt för Apache Web Server) för att hantera felsidor som 404s från Dispatcher-cachen.

  6. GZip komprimerar alla filtyper utom de som är förkomprimerade  - I Apache Web Server, mod_deflate kan användas, men se till att  Variera: Användaragent  header är inte inställt.  I Microsoft IIS använder du Dynamisk komprimering.

    Exempel på konfiguration av Apache (ange endast vissa innehållstyper för att undvika förkomprimerade filtyper):

    AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript

  7. Aktivera /serveStaleOnError   i konfigurationen för /cache - Servera den gamla cachefilen när AEM förekomster ger upphov till fel.

  8. Lägg till /GracePeriod   till /cache-konfigurationen - Ange hur många sekunder en inaktuell, automatiskt ogiltigförklarad resurs fortfarande kan betjänas från cachen efter den senaste publiceringshändelsen ("aktivering").  Detta minskar antalet begäranden som går tillbaka till publiceringsinstanser under en stor publiceringsaktivitet, till exempel"Trädaktivering".

  9. Lägg till regler i /ignoreUrlParams  - Ignorera frågesträngsparametrar som inte är obligatoriska eller som används av programmet.  Detta tillåter cachelagring av URL:er även när en frågesträng finns.

  10. Cachelagra headers för Cache-Control och Last-Modified response  - Använd  /headers  konfiguration för cache-lagring av HTTP-svarshuvuden  Cache-Control  och  Senast ändrad  (och/eller  ETag  om du skickar det från AEM).  Detta underlättar när det gäller att förenkla och optimera cachning på CDN- och webbläsarnivå.  Cachelagring av dessa rubriker gör att bara AEM anger rubrikerna, inte själva webbservern.  Observera att när du gör detta måste du börja skicka sidhuvuden från AEM program.

  11. Cachelagra innehållet så länge som möjligt  och  minska antalet förfrågningar som går tillbaka till AEM  - Optimera rensningsbegäranden genom att aktivera uppdatering av tömningsagenter. Se avsnittet nedan Återhämtning av Dispatcher Flush. Eller använd  /enableTTL  och ange  Cache-Control: max-age=…  för att cachelagra filer så länge som möjligt.  Se nedan om du vill ha mer information om det här ämnet.

Använda TTL

Från och med Dispatcher version 4.1.11, /enableTTL 1 kan ställas in i vilken filkonfiguration som helst.  Den här inställningen gör att cacheminnet för Dispatcher-respekt som angetts i svarshuvudet för HTTP-cache-Control anges.  Dispatcher fungerar med andra ord på ungefär samma sätt som ett CDN där den primära formen av cacheogiltigförklaring inträffar när filerna förfaller.  När du har implementerat detta och börjat skicka  Cache-Control: max-age=…  för alla svar från AEM kan du inaktivera dina Dispatcher-push-agenter i publiceringsinstanserna.

När du har inaktiverat rensningsagenter på publiceringsinstanserna kanske du ändå vill kunna tömma Dispatcher-cachen.  Då kan du använda ACS-kommandon - användargränssnittet Dispatcher Flush.  Det här verktyget installeras på författarinstansen.  Det ger användarna ett användargränssnitt där de kan utföra manuella cachetömningsbegäranden.

I. Steg för att aktivera ogiltiga TTL-format ("Time to Live" eller utgångsdatum):

  1. Ändra källkoden i AEM program som ska skickas  Cache-Control  header och  Senast ändrad  för alla begäranden där det inte redan har angetts.
  2. Installera Dispatcher 4.1.11 eller senare.
  3. Ange  /enableTTL 1  i alla servergruppskonfigurationer för platsen.
  4. Ange  /headers  konfiguration som cachelagrar  Cache-Control  och  Senast ändrad  sidhuvuden.
  5. Starta om webbservern.

II. Inaktivera rensningsagenter för Dispatcher i publiceringsinstanserna:

Dispatcher kommer nu att använda huvudet Cache-Control för att kontrollera ogiltigförklaringen av cachefilerna.  Eftersom så är fallet behövs inte längre Dispatcher som tömmer publiceringsinstanserna.

  1. Gå till /etc/replication/agents.publish.html för varje publiceringsinstans.
  2. Gå till varje rensningsagentkonfiguration och inaktivera agenten.

III. Tillåt manuella begäranden om tömning av Dispatcher från författarinstansen:

Nu när tömningsagenter är inaktiverade använder du helt och hållet  Cache-Control  för att styra när innehåll uppdateras i dispatchern.  Du kan fortfarande tillåta användare att göra manuella tömningar av Dispatcher-cachen:

  1. Installera ACS-kommandon - användargränssnittet Dispatcher Flush på författarinstansen.
  2. Konfigurera rensningsagenter på författarinstansen.
  3. I varje agentkonfiguration anger du  Utlösare  =>   Ignorera standard  till aktiverat. Det här alternativet gör att justeringsagenterna ignoreras när användare klickar på  (Un)Publicera  eller  (De)Aktivera  i AEM.

Återhämtning av Dispatcher Flush

Om du vill optimera begäranden om rensning av dispatcher ska alla rensningsagenter för Dispatcher ha en funktion som kallas uppdatering av tömning aktiverad.

Så här aktiverar du omhämtning av dispatcherns tömning:

  1. Gå till  http://aemhost:port/crx/packmgr/index.jsp  och logga in som administratör.

  2. Hämta paketet från här.

  3. Överför och installera paketet till pakethanteraren.

  4. Gå till konfigurationen för Dispatcher-tömningsagenten. Till exempel  /etc/replication/agents.author/flush.html

  5. Klicka  Redigera

  6. Ange följande

    • Serialiseringstyp  =  Hämta rensning av avsändare igen
    • Utökad  =>   HTTP-metod  =  POST

  7. Klicka  Spara

Obs! Paketet ovan är bara ett grundläggande exempel.  Om du vill anpassa och optimera omhämtning kan du ändra listan med URI:er som skickas.  Koden är öppen källkod och kan hittas här.  Koden lägger till en lista med URI:er i begärandetexten som parametrar som talar om för Dispatcher vilka sökvägar som ska hämtas igen.  Du kan lägga till fler sökvägar enligt dina programkrav för att optimera webbplatsens cachningsfunktioner.

Detaljerad förklaring om återhämtning av tömning

Normalt fungerar en rensning av Dispatcher genom att filer tas bort:

  1. Peka på .stat-fil(er)
  2. Ta bort /content/foo.*
  3. Ta bort /content/foo/_jcr_content

På grund av att filer tas bort i steg 2 kommer efterföljande förfrågningar om samma fil att skickas till publiceringsinstanserna nästa gång en användare begär en fil som /content/foo.html eller /content/foo.json, medan filen"hämtas igen".  För långsamma svar eller sidor med stor trafik, till exempel hemsidor, kan detta orsaka att publiceringsinstansnivån flödar.

Du löser det här problemet genom att aktivera en funktion i Dispatcher som kallas refetching.  Med den här funktionen kan du skicka en lista över URI:er som Dispatcher proaktivt ska"hämta om" och ersätta istället borttagning.

Se 22:41-27:05 i detta presentationsinspelning för en demonstration av hur det fungerar och hur du konfigurerar det.

recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f