Invalidierung zwischengespeicherter Seiten aus AEM invalidating-cached-pages-from-aem

Bei Verwendung des Dispatchers mit AEM muss die Interaktion konfiguriert werden, um eine effektive Cacheverwaltung zu ermöglichen. Je nach Umgebung kann die Konfiguration auch zu einer Leistungsverbesserung führen.

Einrichten von AEM-Benutzerkonten setting-up-aem-user-accounts

Das Standardbenutzerkonto admin wird zur Authentifizierung der Replikationsagenten verwendet, die standardmäßig installiert sind. Erstellen Sie ein dediziertes Benutzerkonto zur Verwendung mit Replikationsagenten.

Weitere Informationen finden Sie im Abschnitt Konfigurieren von Benutzerreplikation und -transport der Checkliste für die AEM-Sicherheit.

Invalidierung des Dispatcher-Caches aus der Autorenumgebung invalidating-dispatcher-cache-from-the-authoring-environment

Ein Replikationsagent auf der AEM-Autoreninstanz sendet eine Anforderung zur Invalidierung des Caches an den Dispatcher, wenn eine Seite veröffentlicht wird. Der Dispatcher aktualisiert die Datei schließlich im Cache, wenn neue Inhalte veröffentlicht werden.

Gehen Sie wie folgt vor, um einen Replikationsagenten auf der AEM-Autoreninstanz zu konfigurieren. Die Konfiguration macht den Dispatcher-Cache bei Seitenaktivierung ungültig:

Sie können den Dispatcher-Flush-Agenten auch über die Touch-optimierte Benutzeroberfläche von AEM aufrufen und konfigurieren.

Weitere Informationen zum Aktivieren des Zugriffs auf Vanity-URLs finden Sie unter Aktivieren des Zugriffs auf Vanity-URLs.

Dieser Ansatz hat zwei mögliche Probleme:

Invalidierung des Dispatcher-Caches von einer Veröffentlichungsinstanz invalidating-dispatcher-cache-from-a-publishing-instance

Unter bestimmten Umständen lassen sich Leistungsverbesserungen erzielen, indem die Cache-Verwaltung von der Autorenumgebung in eine Veröffentlichungsinstanz verlagert wird. Dann sendet die Veröffentlichungsumgebung (nicht die AEM-Autorenumgebung) eine Anfrage zur Cache-Invalidierung an den Dispatcher, wenn eine veröffentlichte Seite empfangen wird.

Beispiele:

Ein Replikationsagent, der auf der Veröffentlichungsinstanz ausgeführt wird, steuert die Dispatcher-Leerung. Allerdings erfolgt die Konfiguration in der Autorenumgebung und wird anschließend übertragen, indem der Agent aktiviert wird:

Wenn Sie nach der Konfiguration eine Seite von Author to Publish aktivieren, initiiert dieser Agent eine Standardreplikation. Das Protokoll enthält Meldungen, die auf Anfragen von Ihrem Publish-Server hinweisen und etwa wie folgt aussehen:

Manuelle Invalidierung des Dispatcher-Caches manually-invalidating-the-dispatcher-cache

Um den Dispatcher-Cache zu invalidieren (oder zu leeren), ohne eine Seite zu aktivieren, können Sie eine HTTP-Anfrage an den Dispatcher ausgeben. Sie können beispielsweise eine AEM-Anwendung erstellen, die es Admins oder anderen Anwendungen ermöglicht, den Cache zu leeren.

Die HTTP-Anfrage führt dazu, dass der AEM-Dispatcher bestimmte Dateien aus dem Cache löscht. Der Dispatcher aktualisiert den Cache dann mit einer neuen Kopie (optional).

Löschen zwischengespeicherter Dateien delete-cached-files

Stellen Sie eine HTTP-Anfrage, durch die der Dispatcher Dateien aus dem Cache löscht. Der Dispatcher speichert die Dateien nur dann erneut im Cache, wenn eine Clientanfrage für die Seite eingeht. Auf diese Weise zwischengespeicherte Dateien zu löschen, empfiehlt sich für Websites mit geringer Wahrscheinlichkeit, gleichzeitige Anfragen für ein und dieselbe Seite zu empfangen.

Die HTTP-Anforderung sieht folgendermaßen aus:

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

Der Dispatcher leert (löscht) die zwischengespeicherten Dateien und Ordner mit Namen, die dem Wert des Headers CQ-Handler entsprechen. Beispielsweise entspricht der CQ-Handle mit dem Wert /content/geomtrixx-outdoors/en:

Alle anderen Dateien im Dispatcher-Cache (bzw. bis zu einer bestimmten Ebene je nach /statfileslevel-Einstellung) werden durch Änderung der .stat-Datei invalidiert. Das Datum der letzten Änderung dieser Datei wird mit dem Datum der letzten Änderung eines zwischengespeicherten Dokuments verglichen. Das Dokument wird erneut abgerufen, wenn die .stat-Datei neuer ist. Weitere Informationen finden Sie unter Invalidierung von Dateien nach Ordnerebene.

Die Invalidierung (d. h. das Ändern von STAT-Dateien) kann durch Senden des zusätzlichen Headers CQ-Action-Scope: ResourceOnly verhindert werden. Mit dieser Funktion können bestimmte Ressourcen geleert werden. Alles ohne Invalidierung anderer Teile des Caches, z. B. JSON-Daten. Diese Daten werden dynamisch erstellt und müssen regelmäßig unabhängig vom Cache geleert werden. Zum Beispiel die Darstellung von Daten, die von einem Drittsystem bezogen werden, um Nachrichten, Börsenticker usw. anzuzeigen.

Löschen und erneutes Zwischenspeichern von Dateien delete-and-recache-files

Geben Sie eine HTTP-Anfrage aus, durch die der Dispatcher zwischengespeicherte Dateien löscht und die Datei unmittelbar abruft und erneut zwischenspeichert. Löschen Sie Dateien und speichern Sie sie sofort erneut im Cache, wenn es wahrscheinlich ist, dass Websites gleichzeitige Anfragen für ein und dieselbe Seite empfangen. Mit dem unmittelbaren erneuten Zwischenspeichern wird sichergestellt, dass der Dispatcher die Seite insgesamt nur einmal abruft und zwischenspeichert, anstatt einmal für jede der gleichzeitigen Client-Anfragen.

Hinweis: Das Löschen und erneute Zwischenspeichern von Dateien sollte ausschließlich in der Veröffentlichungsinstanz erfolgen. Wenn dies auf der Autoreninstanz erfolgt, kann es zu Überschneidungen kommen, wenn versucht wird, Ressourcen erneut zwischenzuspeichern, bevor sie veröffentlicht wurden.

Die HTTP-Anforderung sieht folgendermaßen aus:

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

Die Seitenpfade für das unmittelbare erneute Zwischenspeichern werden im Nachrichtentext in getrennten Zeilen aufgeführt. Der Wert von CQ-Handle ist der Pfad einer Seite, die die erneut zwischenzuspeichernde Seite ungültig macht. (Siehe Parameter /statfileslevel des Konfigurationselements Cache) Die folgende Beispiel-HTTP-Anfragemeldung löscht und wiederholt /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

Beispiel-Servlet für das Leeren des Caches example-flush-servlet

Mit dem folgenden Code wird ein Servlet implementiert, das eine Invalidierungsanfrage an den Dispatcher sendet. Das Servlet empfängt eine Meldung, die die Parameter handle und page enthält. Diese Parameter stellen den Wert des Headers CQ-Handle bereit und dementsprechend auch den Pfad zu der Datei, die erneut zwischengespeichert werden soll. Das Servlet verwendet die Werte, um die HTTP-Anfrage für den Dispatcher zu erstellen.

Wenn das Servlet für die Veröffentlichungsinstanz bereitgestellt wird, veranlasst die folgende URL den Dispatcher dazu, die Seite „/content/geometrixx-outdoors/en.html“ zu löschen und dann eine neue Kopie zwischenzuspeichern.

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

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