Viele von uns kennen vielleicht die Situation, dass der Dispatcher eine alte Codeversion verwendet. Dieser Artikel beschreibt, wie dies vermieden werden kann, während die Caching-Möglichkeiten des Dispatchers genutzt werden.
Invalidierung ist ein Mechanismus zur Identifizierung veralteter zwischengespeicherter Ressourcen. Es gibt Werkzeuge für die automatische und manuelle Invalidierung. Zuerst legen wir die anfängliche Konfiguration für den Invalidierungsbereich der Dispatcher-Konfigurationsdatei fest, lernen dann, wie die Invalidierung auf niedriger Ebene funktioniert, und kehren schließlich zur Analyse der Invalidierungswerkzeuge zurück. Aber zuerst die Grundlagen.
Was ist der Dispatcher-Cache in AEM?
Der Dispatcher ist ein Caching- und Lastenausgleichstool von AEM, das zwischengespeicherte Dateien auf dem Webserver speichert, genau wie eine statische Website. Nach einer Anfrage prüft der Dispatcher ein cachbares Dokument, um festzustellen, ob dieses Dokument im Dateisystem des Webservers vorhanden ist:
- Wenn das Dokument zwischengespeichert ist, gibt der Dispatcher die Datei zurück.
- Der Dispatcher fordert das Dokument von der AEM-Instanz an, wenn es nicht zwischengespeichert ist.
Das Bereitstellen von Daten aus dem Cache des Dispatchers verringert die Last auf AEM-Publish-Instanzen.
/cache
{
/invalidate
{
/0000 { /glob "*" /type "deny" }
/0001 { /glob "*.html" /type "allow" }
}
}
Wie löscht man den Dispatcher-Cache?
Es gibt mindestens 3 Möglichkeiten, den Dispatcher-Cache zu leeren:
- Durch Flush-Agents auf Author und/oder auf Publishes
- Manuelles Flushing
- Benutzerdefinierter Code zum Ausführen des Flushs durch Programmierung
Anfängliche Einstellungen des Invalidierungsbereichs
Kommen wir nun zur Invalidierung von gecachten Seiten aus AEM. Der /invalidate Block innerhalb des /cache-Bereichs bestimmt gecachte Dateien, die bei Inhaltsaktualisierung automatisch invalidiert werden können. Zum Beispiel invalidiert die folgende Konfiguration alle HTML-Seiten:
/cache
{
/invalidate
{
/0000 { /glob "*" /type "allow" }
}
}
Bei der automatischen Invalidierung löscht der Dispatcher keine zwischengespeicherten Dateien nach der Inhaltsaktualisierung, sondern prüft deren Gültigkeit bei der nächsten Anforderung. Dokumente im Cache, die nicht automatisch invalidiert werden, bleiben im Cache, bis sie bei Inhaltsaktualisierungen gelöscht werden. Als Beispiel lassen wir zu, dass der gesamte Cache automatisch invalidiert wird:
Starten Sie den httpd-Server neu, nachdem Sie die /invalidate-Sektion aktualisiert haben, um die neuen Änderungen zu übernehmen.
Invalidierung im Detail
Der Dispatcher verwendet standardmäßig spezielle leere Dateien, „.stat“ auf niedriger Ebene genannt. Der /statfileslevel „0“ Parameter ist standardmäßig gesetzt, was bedeutet, dass nur eine Stat-Datei im Stammverzeichnis des htdocs Ordners verwendet wird. Wenn der Änderungszeitpunkt der Stat-Datei später ist als der Änderungszeitpunkt der Ressource, betrachtet der Dispatcher eine solche Ressource als veraltet oder ungültig.
Zum Beispiel haben wir diese gecachten Ressourcen nach dem Anfordern der Seite http://localhost/content/geometrixx/en/products.html :
Invalidieren wir sie durch Anwendung eines Low-Level-Stat-Datei-Mechanismus. Erstellen Sie eine leere Datei namens „.stat“ im Stammverzeichnis Ihres htdocs-Verzeichnisses:
Sie werden sehen, dass der Änderungszeitpunkt der Stat-Datei später ist als der Änderungszeitpunkt der gecachten Ressourcen. Für den Dispatcher bedeutet dies, dass alle Ressourcen veraltet sind. Dies ist ein Low-Level-Invalidierungsmechanismus. Wenn wir http://localhost/content/geometrixx/en/products.html nach dem Erstellen dieser Stat-Datei erneut besuchen, werden die angeforderten gecachten Ressourcen aktualisiert:
Dieses Beispiel veranschaulicht ein Invalidierungsmuster mit dem Standard- /statfileslevel Parameter „0“. Sehen wir uns an, wie wir die Invalidierung mit dem /statfileslevel Parameter detaillierter anpassen können.
Einstellung von /statfileslevel
Sie können die /statfileslevel Eigenschaften der Dispatcher-Konfigurationsdatei verwenden, um gecachte Dateien selektiv nach ihrem Pfad zu invalidieren. Es gibt einige Regeln für den /statfileslevel-Eigenschaftenmechanismus:
- Der Dispatcher erstellt .stat-Dateien in jedem Ordner, beginnend vom Docroot bis zu der von Ihnen angegebenen Ebene. Die Ebene des Docroot-Ordners ist 0.
- Wenn Sie eine Datei aktualisieren, findet der Dispatcher einen Ordner auf der statfileslevel-Ebene und invalidiert alle Dateien in diesem Ordner sowie alle Dateien, die sich darunter in diesem Ordner befinden.
- Wenn der Level der aktualisierten Datei niedriger ist als der statfileslevel, werden nur die Dateien des Ordners, der die aktualisierte Datei enthält, ungültig gemacht, aber die darunter liegenden Dateien innerhalb dieses Ordners bleiben gültig.
- Beim Aktualisieren einer Datei werden alle Dateien des entsprechenden Ordners und die darüber liegenden bis einschließlich der Root-Ebene ungültig.
Betrachten wir ein paar Beispiele, um die Regeln der Eigenschaft /statfileslevel besser zu verstehen. Unser Standard-Demofall, bei dem /statfileslevel „0“ ist, sieht folgendermaßen aus:
Es gibt nur eine Stat-Datei im Root-Ordner des Docroot. Der Verantwortungsbereich oder Geltungsbereich dieser Stat-Datei erstreckt sich über den gesamten Dateibaum unseres Docroot. Wenn eine Datei im Baum ein älteres Änderungsdatum als das Änderungsdatum der Stat-Datei hat, betrachtet der Dispatcher diese Datei als ungültig.
Wenn wir /statfileslevel „4“ setzen, funktioniert die Invalidierung so:
Stat-Dateien existieren auf allen Ebenen von 0 (Root) bis 4.
Eine Stat-Datei auf einer Ebene unter 4 hat einen Geltungsbereich oder Verantwortungsbereich nur für den Ordner, der sie enthält. Wenn eine Stat-Datei im Ordner content/geometrixx/en neuer ist als irgendeine Datei aus diesem Ordner, dann ist diese Datei ungültig, aber alle Dateien aus anderen Ordnern werden durch andere Stat-Dateien definiert.
Nur Stat-Dateien mit dem Wert statfileslevel (in unserem Fall ist der Level 4) haben den Geltungsbereich oder Verantwortungsbereich des gesamten darunterliegenden Baums, beginnend mit dem Ordner, der eine solche Stat-Datei enthält, und sich bis zu den unteren Ebenen des Dateibaums erstreckend.
Wenn also eine Stat-Datei im Ordner content/geometrixx/en/products ein neueres Änderungsdatum hat als jede Datei im darunterliegenden Dateibaum, der den products-Ordner einschließt, betrachtet der Dispatcher diese Datei als ungültig. Die Validierung aller Dateien, die sich nicht in diesem Baum befinden, wird durch andere Stat-Dateien bestimmt.
Automatische Invalidierung und Dispatcher Flush Agent AEM
Um die Invalidierung zu automatisieren, können Sie Authoring- oder Publish-Flush-Agents aktivieren. Wir empfehlen die Verwendung des Publish-Flush-Agents für eine zuverlässigere automatische Invalidierung, da die Verwendung des Authoring-Flush-Agents folgende Probleme verursachen kann:
- Der Dispatcher muss für den AEM-Server des Autors zugänglich sein. Wenn Ihr Netzwerk (z. B. aufgrund einer Firewall) so eingerichtet ist, dass der Zugriff zwischen beiden verweigert wird, funktioniert die automatische Invalidierung nicht.
- Veröffentlichung und Cache-Invalidierung erfolgen gleichzeitig. Ein Benutzer kann eine Seite sofort anfordern, nachdem sie aus dem Cache entfernt wurde, aber bevor die Seite veröffentlicht wurde. In dieser Situation gibt AEM die alte Seite zurück, und der Dispatcher speichert sie erneut im Cache und betrachtet sie nun als gültig. Dieses Problem betrifft hauptsächlich große Websites.
Der Public Flush Agent befindet sich unter: http://localhost:4503/etc/replication/agents.publish/flush.html
Um Ihren Publish-Flush-Agent zu aktivieren, klicken Sie auf die Schaltfläche „Bearbeiten“ und aktivieren Sie das Kontrollkästchen „Aktiviert“:
Aktualisieren Sie den URI-Port auf der Registerkarte „Transport“ und setzen Sie seinen Wert auf 80:
Speichern Sie Ihre Änderungen, und Sie werden sehen, dass der Publish-Flush-Agent aktiviert ist:
Manuelle Invalidierungsanfragen
Sie können die folgenden Anfragen senden, um Ihre zwischengespeicherten Ressourcen manuell zu invalidieren:
- zum Löschen zwischengespeicherter Dateien
POST /dispatcher/invalidate.cache HTTP/1.1
CQ-Action: Activate
CQ-Handle: path-pattern
Content-Length: 0
- zum Löschen und erneuten Zwischenspeichern von Dateien
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
Zusammenfassung
Als Ergebnis haben wir herausgefunden, wie diese Dinge funktionieren:
- Low-Level-Invalidierungsmechanismus;
- Flush-Agents für die automatische Invalidierung nach der Veröffentlichung von Seiten;
- Manuelle Invalidierungsabfragen.
Detailliertere und nützlichere Dokumentation ist auf den folgenden Seiten verfügbar:
http://docs.adobe.com/docs/en/dispatcher/disp-config.html
http://docs.adobe.com/docs/en/dispatcher/page-invalidate.html
FAQ
Wie löscht man den Dispatcher-Cache in AEM?
Es gibt mindestens 3 Wege, den Dispatcher-Cache in AEM zu leeren:
- Durch Flush-Agents auf Author und/oder auf Publishes
- Manuelles Flushing
- Benutzerdefinierter Code zum Ausführen des Flushs durch Programmierung
Was ist der Dispatcher-Cache in AEM?
Der Dispatcher ist ein AEM Caching- und Load-Balancing-Tool, das gecachte Dateien auf dem Webserver speichert, genauso wie es eine statische Website tut.
Wie überprüft man Dispatcher-Logs in AEM?
Die Dispatcher-Logs werden innerhalb der Dispatcher-Modulkonfiguration gesteuert. Je nach Ihrer Einrichtung kann dies entweder eine separate .conf-Datei in /etc/httpd/conf.d oder innerhalb derselben Datei wie die Dispatcher-vhost-Konfiguration sein.
Was ist der Unterschied zwischen Cache-Flush und Invalidierung in AEM?
Gemäß der Dokumentation bedeuten sowohl Flush als auch Invalidierung dasselbe.
„Um den Dispatcher-Cache zu invalidieren (oder zu leeren), ohne eine Seite zu aktivieren, können Sie eine HTTP-Anfrage an den Dispatcher senden.“
Man kann jedoch sagen, dass Invalidierung ein HTTP-Aufruf an den Dispatcher ist, um die gecachte Ressource als ungültig zu markieren (dasselbe geschieht, wenn die TTL der Ressource abläuft). Während Flush normalerweise eine Invalidierung bedeutet, die von der Author-/Publish-Instanz ausgelöst wird, wenn der Inhalt veröffentlicht wird.
