Hur optimerar jag Dispatcher-cachen?

I den här artikeln finns detaljerade anvisningar om de olika sätten att optimera dispatchercachen. Den beskriver vidare stegen för att aktivera invalideringar av TTL-format ("Time to Live" eller utgångsdatum), inaktivera bl.a. agenter för flyttspolning och omhämtning av tömning av dispatcher.

Beskrivning description

Miljö

Adobe Experience Manager

Problem/symtom

Den här artikeln fokuserar på de senaste optimeringarna i AEM och hur du bäst utnyttjar dem. AEM ä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 avsändarmodulen 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:

Optimera Dispatcher-cachen

Här är några sätt att optimera dispatchercachen:

  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 dispatchercachen för en direktdispatcher  - Om en dispatcher skickar live-innehåll och du tar bort cachen, kommer detta att få en enorm mängd förfrågningar att skickas tillbaka till AEM.  På grund av detta bör dispatchercachen aldrig tas bort för en direktdispatcher.

  4. Använd cachen  - Innan du tar bort dispatchercachen drar du ut dispatchern från belastningsutjämnaren, tar bort cachen och kör sedan ett webbarbetsverktyg för att cachelagra filer på dispatchern 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 anges i .any-filkonfigurationen.  Den här inställningen gör att cacheminnet för avsändarrespekt anges i svarshuvudet för HTTP Cache-Control.  Med andra ord fungerar dispatchern 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 dispatcherrensningsagenter på ett säkert sätt i publiceringsinstanserna.

När du har inaktiverat rensningsagenter på publiceringsinstanserna kanske du ändå vill kunna tömma dispatchercachen.  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 servergruppskonfigurationen 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 på publiceringsinstanserna:

Dispatcharen 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 någon 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 dispatchercachen:

  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 tömning 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 dispatcher-rensning:

  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 din konfiguration för rensningsagent för dispatcher. 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 en 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 dispatchern som kallas omhämtning.  Med den här funktionen kan du skicka en lista över URI:er som dispatchern proaktivt ska"hämta om" och ersätta borttagningen i stället för att ta bort.

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