Übersicht

Dieser Artikel konzentriert sich auf die neuesten Optimierungen im AEM-Dispatcher und deren bestmögliche Nutzung.  Der AEM-Dispatcher ist ein Reverseproxy-Server zur Zwischenspeicherung, der für die Verwendung mit Adobe Experience Manager konzipiert wurde.  Es kann installiert werden und läuft als ein Modul in vorhandener Webserver-Software.  Zum Zeitpunkt der Erstellung dieses Artikels wird das Dispatcher-Modul auf Apache HTTP Server, Microsoft IIS und iPlanet unterstützt.

Funktionsweise des Dispatcher-Caching

Auf der untersten Ebene ist der AEM-Dispatcher ein Reverse-Proxy, der Caching, Cache-Flushing und Cache-Ungültigmachung durchführt.  

Weitere Informationen zum Dispatcher finden Sie über die zugehörigen Links:

  1. Wie der Dispatcher funktioniert und wie er installiert wird.
  2. Konfigurationsoptionen im Dispatcher verfügbar.
  3. Webinar zur Funktionsweise des Dispatchers – Beachten Sie, dass einige Informationen in der Präsentation auf alten Versionen des Dispatchers basieren.
  4. Gems Webinar-Sitzung zu Dispatcher-Funktionen, CDN-Nutzung und Sicherheit.
  5. Gems-Sitzung zu neueren Funktionen im Dispatcher (nach v4.1.9).

Optimieren des Dispatcher-Cache

Es folgen einige Möglichkeiten zur Optimierung des Dispatcher-Cache:

  1. Fast alle Daten zwischenspeichern – Das bedeutet, dass alle Inhalte, die von Benutzern mehr als ein Mal angefordert werden, im Cache gespeichert werden.
  2. Cache-personalisierter Inhalt für verschiedene Zeiträume – Wenn Ihre Website personalisierten Inhalt aufweist, sollten Sie die Verwendung von Apache Sling Dynamic Includes in Ihrer AEM-Anwendung in Betracht ziehen, um Ajax (asynchrone JavaScript- und XML-Aufrufe auf Browserebene), SSI (Server Side Includes auf Webserverebene) und ESI (Edge-side Includes auf CDN-Ebene) zum Zwischenspeichern verschiedener Teile der Seite für unterschiedliche Zeiträume zu nutzen.
  3. Löschen Sie niemals den Dispatcher-Cache auf einem Live-Dispatcher – Wenn ein Dispatcher Live-Inhalte bereitstellt und Sie den Cache löschen, führt dies zu einer massiven Flut von Anfragen, die zurück an AEM gehen.  Aus diesem Grund sollte der Dispatcher-Cache niemals auf einem Live-Dispatcher gelöscht werden.
  4. Bereiten Sie den Cache vor – Bevor Sie den Dispatcher-Cache löschen, ziehen Sie den Dispatcher von Ihrem Lastverteiler ab. Dann löschen Sie den Cache und verwenden ein Webcrawler-Tool, um Dateien auf dem Dispatcher zwischenzuspeichern, bevor Sie sie auf den Lastverteiler legen.
  5. Cache-Fehlerseiten – Nutzen Sie die Anweisung DispatcherPassError 1 (Apache Web Server-spezifisch), um Fehlerseiten wie 404s aus dem Dispatcher-Cache bereitzustellen.
  6. GZip komprimiert alle Dateitypen mit Ausnahme derer, die vorkomprimiert sind – In Apache Web-Server kann mod_deflate verwendet werden, stellen Sie aber sicher, dass der Header Vary: User-Agent nicht gesetzt ist.  Verwenden Sie in Microsoft IIS Dynamische Komprimierung.
  7. Enable /serveStaleOnError – Stellt die alte Cachedatei bereit, wenn AEM-Instanzen Fehler ausgeben.
  8. Fügen Sie Regeln zu /ignoreUrlParams hinzu – ignorieren Sie Abfragezeichenfolgeparameter, die von der Anwendung nicht benötigt oder verwendet werden.  Dies ermöglicht das Zwischenspeichern von URLs, selbst wenn eine Abfragezeichenfolge vorhanden ist.
  9. Cache-Control- und Last-Modified-Response-Header zwischenspeichern – Verwenden Sie die /headers-Konfiguration, um die HTTP-Response-Header Cache-Control und Zuletzt geändert zwischenzuspeichern (und/oder den Header ETag, wenn Sie ihn von AEM senden).  Dies vereinfacht und optimiert das Zwischenspeichern auf CDN- und Browser-Ebene.  Durch das Zwischenspeichern dieser Header wird festgelegt, dass die Header nur von AEM und nicht vom Webserver selbst festlegt werden.  Beachten Sie, dass Sie dann die Header von Ihrer AEM-Anwendung senden müssen, wenn Sie dies tun.
  10. Inhalte so lange wie möglich zwischenspeichern und Anfragen reduzieren, die auf AEM zurückgehen – Optimieren Sie Flush-Anfragen, indem Sie Flush auf allen Flush-Agenten aktivieren.  Verwenden Sie /enableTTL und setzen Sie den Header Cache-Control: max-age = ..., um die Dateien so lange wie möglich zwischenzuspeichern.  Näheres zu diesem Thema finden Sie unten.

Verwenden von TTLs

Ab der Dispatcher-Version 4.2.3 kann /enableTTL 1 in der .any-Dateikonfiguration festgelegt werden.  Diese Einstellung bewirkt, dass der Dispatcher die im HTTP-Cache-Control-Antwortheader festgelegten Cache-Abläufe berücksichtigt.  Mit anderen Worten funktioniert der Dispatcher ähnlich wie ein CDN, bei dem die primäre Form der Cache-Ungültigmachung stattfindet, wenn Dateien ablaufen.  Sobald Sie dies implementieren und Cache-Control: max-age = ... für alle Antworten von AEM senden, können Sie Ihre Dispatcher-Räumagenten in den Veröffentlichungsinstanzen sicher deaktivieren.

Nach dem Deaktivieren der Flush-Agenten in den Veröffentlichungsinstanzen können Sie den Dispatcher-Cache dennoch leeren.  Dazu verwenden Sie ACS Commons – Dispatcher Flush UI.  Dieses Tool wird in der Autoreninstanz installiert.  Es bietet Benutzern eine Benutzeroberfläche, auf der sie manuelle Cache-Flush-Anfragen durchführen können.

I. Schritte zum Aktivieren der Ungültigmachung von TTL (Time to Live, Lebenszeit bzw. Ablauf):

  1. Ändern Sie den Quellcode in der AEM-Anwendung, um Cache-Control-Header und Zuletzt geändert für alle Anforderungen zu senden, bei denen dies noch nicht festgelegt wurde.
  2. Installieren Sie Dispatcher 4.2.3 oder höher.
  3. Setzen Sie /enableTTL 1 in der .fany-Farmkonfiguration der Site.
  4. Setzen Sie die /headers -Konfiguration so, dass die Header Cache-Control und Zuletzt geändert zwischengespeichert werden.
  5. Starten Sie den Webserver neu.

II. Deaktivieren Sie Dispatcher-Flush-Agenten für die Veröffentlichungsinstanzen:

Der Dispatcher verwendet nun den Cache-Control-Header, um die Ungültigmachung der Cache-Dateien zu steuern.  Da dies der Fall ist, ist das Dispatcher-Flushing von den Veröffentlichungsinstanzen nicht mehr erforderlich.

  1. Gehen Sie zu /etc/replication/agents.publish.html für jede Veröffentlichungsinstanz.
  2. Gehen Sie zur Konfiguration jedes Agenten und deaktivieren Sie den Agenten.

III. Erlauben Sie manuelle Dispatcher-Flush-Anfragen von der Autoreninstanz:

Da die Flush-Agenten nun deaktiviert sind, würden Sie sich gänzlich auf den Header Cache-Control verlassen, um zu steuern, wann der Inhalt auf dem Dispatcher aktualisiert wird.  Sie können Benutzern weiterhin das manuelle Löschen des Dispatcher-Cache erlauben:

  1. Installieren Sie ACS Commons – Dispatcher Flush UI für die Autoreninstanz.
  2. Konfigurieren Sie Flush-Agenten für die Autoreninstanz.
  3. Aktivieren Sie in jeder der Agentenkonfigurationen die Option Trigger => Standard ignorieren. Mit dieser Option werden die Flush-Agenten ignoriert, wenn Benutzer in der AEM-Benutzeroberfläche auf Veröffentlichen/Veröffentlichung aufheben oder Aktivieren/Deaktivieren klicken.

Dispatcher-Flush erneut abrufen

Zur Optimierung von Dispatcher-Flush-Anfragen sollte bei allen Dispatcher-Flush-Agenten eine Funktion namens „Refetching Flush“ aktiviert sein.

Um das erneute Abrufen von Dispatcher-Flush zu ermöglichen, gehen Sie wie folgt vor:

  1. Gehen Sie zu http://aemhost:port/crx/packmgr/index.jsp und melden Sie sich als Administrator an.
  2. Laden Sie das Paket hier herunter.
  3. Laden Sie das Paket hoch und installieren Sie es im Paketmanager.
  4. Gehen Sie zu Ihrer Dispatcher-Agentenkonfiguration. Beispiel: /etc/replication/agents.author/flush.html
  5. Klicken Sie auf Bearbeiten
  6. Stellen Sie Folgendes ein:
    • Serialisierungstyp = Dispatcher-Flush erneut abrufen
    • Erweitert => HTTP-Methode = POST
  7. Klicken Sie auf Speichern

Beachten Sie, dass das oben installierte Paket nur ein einfaches Beispiel ist.  Um das erneute Abrufen von Flush anzupassen und zu optimieren, können Sie die Liste der URIs ändern, die gesendet werden.  Den Code „Open Source“ finden Sie hier.  Der Code fügt dem Anfragetext eine Liste von URIs als Parameter hinzu, die den Dispatcher informieren, welche Pfade erneut abgerufen werden sollen.  Je nach den Anforderungen Ihrer Anwendung können Sie weitere Pfade hinzufügen, um die Caching-Funktionen Ihrer Site zu optimieren.

Eine ausführlichere Erklärung für das erneute Abrufen von Flush

Normalerweise funktioniert ein Dispatcher-Flush, indem er Dateien löscht:

  1. Touch .stat-Datei(en)
  2. Löschen Sie /content/foo.*
  3. Löschen Sie /content/foo/_jcr_content

Aufgrund der Tatsache, dass Dateien in Schritt zwei gelöscht werden, werden nachfolgende Anforderungen für die gleiche Datei ebenfalls an die Veröffentlichungsinstanzen gesendet, bis die Datei zwischengespeichert ist, wenn ein Benutzer das nächste Mal eine Datei wie /content/foo.html oder /content/foo.json anfordert, während die Datei „erneut abgerufen“ wird.  Bei langsamen Antworten oder Seiten mit starkem Verkehr wie Startseiten kann dies zu einer Überflutung der Veröffentlichungsinstanzebene führen.

Um dieses Problem zu lösen, aktivieren Sie eine Funktion des Dispatchers, die als erneutes Abrufen bezeichnet wird.  Mit dieser Funktion können Sie eine Liste von URIs senden, die der Dispatcher initiativ „erneut abrufen“ und ersetzen statt löschen soll.

Eine Demo der Funktionsweise und Konfiguration finden Sie unter 22:41–27:05 in dieser Präsentationsaufzeichnung.

Dieses Werk unterliegt den Bedingungen der Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.  Twitter™- und Facebook-Beiträge fallen nicht unter die Bedingungen der Creative Commons-Lizenz.

Rechtliche Hinweise   |   Online-Datenschutzrichtlinie