Invaliderar cachelagrade sidor från AEM invalidating-cached-pages-from-aem

När du använder Dispatcher med AEM måste interaktionen konfigureras för att säkerställa effektiv cachehantering. Beroende på din miljö kan konfigurationen även öka prestandan.

Konfigurera AEM användarkonton setting-up-aem-user-accounts

Standardvärdet admin användarkontot används för att autentisera de replikeringsagenter som är installerade som standard. Skapa ett dedikerat användarkonto som kan användas med replikeringsagenter.

Mer information finns i Konfigurera replikerings- och transportanvändare i AEM Security Checklist.

Dispatcher Cache har inte verifierats från redigeringsmiljön invalidating-dispatcher-cache-from-the-authoring-environment

En replikeringsagent på AEM författarinstans skickar en cacheogiltigförklaring till Dispatcher när en sida publiceras. Dispatcher uppdaterar filen så småningom i cachen när nytt innehåll publiceras.

Använd följande procedur för att konfigurera en replikeringsagent på AEM författarinstans. Konfigurationen gör Dispatcher-cachen ogiltig vid sidaktivering:

  1. Öppna AEM verktygskonsol. (https://localhost:4502/miscadmin#/etc)

  2. Öppna den nödvändiga replikeringsagenten under Verktyg/replikering/Agenter på författare. Du kan använda agenten Dispatcher Flush som är installerad som standard.

  3. Klicka på Redigera och kontrollera på fliken Inställningar att Aktiverad är markerat.

  4. (valfritt) Markera alternativet Aliasuppdatering alternativ.

  5. Gå till Dispatcher på fliken Transport genom att ange URI:n.

    Om du använder standardagenten Dispatcher Flush uppdaterar du värdnamnet och porten, till exempel https://<dispatcherHost>:<portApache>/dispatcher/invalidate.cache

    Obs! För Dispatcher Flush-agenter används URI-egenskapen endast om du använder sökvägsbaserade virtuella värdposter för att skilja mellan grupper. Du använder det här fältet för att ange gruppen som ogiltig. Servergrupp #1 har till exempel en virtuell värd för www.mysite.com/path1/* och grupp 2 har en virtuell värd för www.mysite.com/path2/*. Du kan använda en URL med /path1/invalidate.cache för att rikta in sig på den första gården och /path2/invalidate.cache för den andra gruppen. Mer information finns i Använda Dispatcher med flera domäner.

  6. Konfigurera andra parametrar efter behov.

  7. Klicka på OK så att du kan aktivera agenten.

Du kan även få åtkomst till och konfigurera agenten för borttagning av patcher från Gränssnitt för AEM Touch.

Mer information om hur du aktiverar åtkomst till mål-URL:er finns i Aktivera åtkomst till Vanity-URL:er.

NOTE
Agenten för tömning av Dispatcher-cachen behöver inget användarnamn och lösenord, men om den är konfigurerad skickas de med grundläggande autentisering.

Det finns två möjliga problem med den här metoden:

  • Dispatcher måste kunna nås från utvecklingsinstansen. Om ditt nätverk (till exempel brandväggen) är konfigurerat så att åtkomsten mellan dessa två är begränsad, kanske detta inte är fallet.

  • Publicering och cacheminnet blir ogiltiga samtidigt. Beroende på tidpunkten kan en användare begära en sida precis efter att den tagits bort från cachen, och precis innan den nya sidan publiceras. AEM returnerar nu den gamla sidan och Dispatcher cachelagrar den igen. Det här är mer en fråga för stora sajter.

Invaliderar Dispatcher Cache från en publiceringsinstans invalidating-dispatcher-cache-from-a-publishing-instance

Under vissa omständigheter kan du göra prestandavinster genom att överföra cachehantering från redigeringsmiljön till en publiceringsinstans. Det är då publiceringsmiljön (inte den AEM redigeringsmiljön) som skickar en cacheogiltigförklaring till Dispatcher när en publicerad sida tas emot.

Dessa omständigheter omfattar följande:

NOTE
En erfaren AEM bör fatta beslut om att använda den här metoden.

En replikeringsagent som körs på publiceringsinstansen styr rensningen av Dispatcher. Konfigurationen görs dock i redigeringsmiljön och överförs sedan genom att agenten aktiveras:

  1. Öppna AEM verktygskonsol.

  2. Öppna den nödvändiga replikeringsagenten under Verktyg/replikering/Agenter vid publicering. Du kan använda agenten Dispatcher Flush som är installerad som standard.

  3. Klicka på Redigera och kontrollera på fliken Inställningar att Aktiverad är markerat.

  4. (valfritt) Markera alternativet Aliasuppdatering alternativ.

  5. Gå till Dispatcher på fliken Transport genom att ange önskad URI.
    Om du använder standardagenten Dispatcher Flush ska du uppdatera värdnamnet och porten, till exempel http://<dispatcherHost>:<portApache>/dispatcher/invalidate.cache

    Obs! För Dispatcher Flush-agenter används URI-egenskapen endast om du använder sökvägsbaserade virtuella värdposter för att skilja mellan grupper. Du använder det här fältet för att ange gruppen som ogiltig. Servergrupp #1 har till exempel en virtuell värd för www.mysite.com/path1/* och grupp 2 har en virtuell värd för www.mysite.com/path2/*. Du kan använda en URL med /path1/invalidate.cache för att rikta in sig på den första gården och /path2/invalidate.cache för den andra gruppen. Mer information finns i Använda Dispatcher med flera domäner.

  6. Konfigurera andra parametrar efter behov.

  7. Logga in på publiceringsinstansen och validera justeringsagentens konfiguration. Kontrollera även att det är aktiverat.

  8. Upprepa för alla publiceringsinstanser som påverkas.

När du har konfigurerat och aktiverar en sida från författaren till publiceringen initierar den här agenten en standardreplikering. Loggen innehåller meddelanden som anger begäranden från din publiceringsserver, som i följande exempel:

  1. <publishserver> 13:29:47 127.0.0.1 POST /dispatcher/invalidate.cache 200

Invalidera Dispatcher-cachen manuellt manually-invalidating-the-dispatcher-cache

Om du vill göra Dispatcher-cachen ogiltig (eller tömma) utan att aktivera en sida kan du skicka en HTTP-begäran till Dispatcher. Du kan till exempel skapa ett AEM program som gör att administratörer eller andra program kan tömma cachen.

HTTP-begäran gör att Dispatcher tar bort specifika filer från cachen. Dispatcher kan sedan uppdatera cachen med en ny kopia.

Ta bort cachelagrade filer delete-cached-files

Skicka en HTTP-begäran som gör att Dispatcher tar bort filer från cachen. Dispatcher cachelagrar filerna igen endast när de tar emot en klientbegäran för sidan. Att ta bort cachelagrade filer på det här sättet är lämpligt för webbplatser som sannolikt inte tar emot samtidiga begäranden för samma sida.

HTTP-begäran har följande format:

POST /dispatcher/invalidate.cache HTTP/1.1
CQ-Action: Activate
CQ-Handle: path-pattern
Content-Length: 0

Dispatcher tömmer (tar bort) de cachelagrade filer och mappar som har namn som matchar värdet i CQ-Handler header. Till exempel en CQ-Handle av /content/geomtrixx-outdoors/en matchar följande objekt:

  • Alla filer (med valfritt filtillägg) namngivna en i geometrixx-outdoors katalog

  • Alla kataloger med namn _jcr_content nedanför en katalog (som, om den finns, innehåller cachelagrade återgivningar av sidans undernoder)

Alla andra filer i Dispatcher-cachen (eller upp till en viss nivå, beroende på /statfileslevel inställning) ogiltigförklaras genom att .stat -fil. Filens senaste ändringsdatum jämförs med det senaste ändringsdatumet för ett cachelagrat dokument och dokumentet hämtas igen om .stat filen är nyare. Se Ogiltiga filer per mappnivå för mer information.

Invalidering (d.v.s. beröring av .stat-filer) kan förhindras genom att en extra rubrik skickas CQ-Action-Scope: ResourceOnly. Den här funktionen kan användas för att tömma vissa resurser. Allt utan att andra delar av cachen blir ogiltiga, som JSON-data. Dessa data skapas dynamiskt och kräver regelbunden tömning oberoende av cachen. Som exempel kan du representera data som hämtas från ett tredjepartssystem för att visa nyheter, aktiekurser och så vidare.

Ta bort och cacha filer delete-and-recache-files

Skicka en HTTP-begäran som får Dispatcher att ta bort cachelagrade filer och omedelbart hämta och cacha filen. Ta bort och cachelagra omedelbart om filer när det är troligt att webbplatser tar emot samtidiga klientbegäranden för samma sida. Omedelbar cachelagring säkerställer att Dispatcher bara hämtar och cachelagrar sidan en gång, i stället för en gång för varje samtidig klientbegäran.

Obs! Borttagning och cachelagring av filer bör endast utföras på publiceringsinstansen. När det utförs från författarinstansen inträffar konkurrensförhållanden när försök att hämta resurser görs innan de har publicerats.

HTTP-begäran har följande format:

POST /dispatcher/invalidate.cache HTTP/1.1
CQ-Action: Activate
`Content-Type: text/plain
CQ-Handle: path-pattern
Content-Length: numchars in bodypage_path0

page_path1
...
page_pathn

De sidsökvägar som ska cachelagras omedelbart visas på separata rader i meddelandetexten. Värdet för CQ-Handle är sökvägen till en sida som gör sidorna ogiltiga. (Se /statfileslevel parametern för Cache konfigurationsobjekt.) Följande exempel på HTTP-begäran tar bort och cachelagrar /content/geometrixx-outdoors/en.html page:

POST /dispatcher/invalidate.cache HTTP/1.1
CQ-Action: Activate
Content-Type: text/plain
CQ-Handle: /content/geometrixx-outdoors/en/men.html
Content-Length: 36

/content/geometrixx-outdoors/en.html

Exempel på tömningsservett example-flush-servlet

I följande kod implementeras en servlet som skickar en invalideringsbegäran till Dispatcher. Servern tar emot ett begärandemeddelande som innehåller handle och page parametrar. De här parametrarna anger värdet för CQ-Handle sidhuvud och sidans sökväg till cachelagring. Servern använder värdena för att konstruera HTTP-begäran för Dispatcher.

När servern distribueras till publiceringsinstansen gör följande URL att Dispatcher tar bort /content/geometrixx-outdoors/en.html och sedan cachelagrar en ny kopia.

10.36.79.223:4503/bin/flushcache/html?page=/content/geometrixx-outdoors/en.html&handle=/content/geometrixx-outdoors/en/men.html

NOTE
Den här exempelservern är inte säker och visar bara hur HTTP Post-begärandemeddelandet används. Lösningen bör skydda åtkomsten till serverutrymmet.
package com.adobe.example;

import org.apache.felix.scr.annotations.Component;
import org.apache.felix.scr.annotations.Service;
import org.apache.felix.scr.annotations.Property;

import org.apache.sling.api.SlingHttpServletRequest;
import org.apache.sling.api.SlingHttpServletResponse;
import org.apache.sling.api.servlets.SlingSafeMethodsServlet;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import org.apache.commons.httpclient.*;
import org.apache.commons.httpclient.methods.PostMethod;
import org.apache.commons.httpclient.methods.StringRequestEntity;

@Component(metatype=true)
@Service
public class Flushcache extends SlingSafeMethodsServlet {

 @Property(value="/bin/flushcache")
 static final String SERVLET_PATH="sling.servlet.paths";

 private Logger logger = LoggerFactory.getLogger(this.getClass());

 public void doGet(SlingHttpServletRequest request, SlingHttpServletResponse response) {
  try{
      //retrieve the request parameters
      String handle = request.getParameter("handle");
      String page = request.getParameter("page");

      //hard-coding connection properties is a bad practice, but is done here to simplify the example
      String server = "localhost";
      String uri = "/dispatcher/invalidate.cache";

      HttpClient client = new HttpClient();

      PostMethod post = new PostMethod("https://"+host+uri);
      post.setRequestHeader("CQ-Action", "Activate");
      post.setRequestHeader("CQ-Handle",handle);

      StringRequestEntity body = new StringRequestEntity(page,null,null);
      post.setRequestEntity(body);
      post.setRequestHeader("Content-length", String.valueOf(body.getContentLength()));
      client.executeMethod(post);
      post.releaseConnection();
      //log the results
      logger.info("result: " + post.getResponseBodyAsString());
      }
  }catch(Exception e){
      logger.error("Flushcache servlet exception: " + e.getMessage());
  }
 }
}
recommendation-more-help
ce382601-480f-4a99-8be7-73178d4b6ef5