Dokumentation

Wie kann der Dispatcher-Cache optimiert werden?

Last update: Tue Jul 16 2024 00:00:00 GMT+0000 (Coordinated Universal Time)

Dieser Artikel enthält detaillierte Anweisungen zu den verschiedenen Methoden zur Optimierung des Dispatcher-Cache. Außerdem werden die Schritte zum Aktivieren von TTL-Invalidierungen ("Time to Live" oder "Expiration"), zum Deaktivieren von Dispatcher Flush-Agenten, zum erneuten Abrufen von Dispatcher Flush usw. beschrieben.

Beschreibung description

Umgebung

Adobe Experience Manager

Probleme/Symptome

Dieser Artikel konzentriert sich auf die neuesten Optimierungen in der AEM Dispatcher und wie diese am besten genutzt werden können. Der AEM Dispatcher ist ein Cache-Server mit dem Namen Reverse Proxy , der für die Verwendung mit Adobe Experience Manager entwickelt wurde. Es kann als Modul in einer bestehenden Webserver-Software installiert und ausgeführt werden. Zum Zeitpunkt des Schreibens dieses Artikels wird das Modul Dispatcher auf Apache HTTP Server, Microsoft IIS und iPlanet unterstützt.

Auflösung resolution

Wie funktioniert das Dispatcher-Caching?

Auf der grundlegendsten Ebene ist der AEM Dispatcher ein Reverse-Proxy, der durch Zwischenspeicherung, Cache-Leerung und Cache-Invalidierung funktioniert.

Weitere Informationen zu Dispatcher finden Sie unter den entsprechenden Links:

  1. Funktionsweise von Dispatcher und Installation.
  2. In der Dispatcher verfügbare Konfigurationsoptionen.
  3. Webinar zur Funktionsweise von Dispatcher - Beachten Sie, dass einige Informationen in der Präsentation auf alten Versionen des Dispatchers basieren.
  4. Gems-Webinarsitzung zu Dispatcher-Funktionen, CDN-Nutzung und -Sicherheit.
  5. Gems-Sitzung zu neueren Funktionen in Dispatcher (nach v4.1.9).

Optimieren des Dispatcher-Caches

Im Folgenden finden Sie einige Möglichkeiten, den Dispatcher-Cache zu optimieren:

  1. Fast alles zwischenspeichern - Dies bedeutet, dass alle Inhalte zwischengespeichert werden, die von Benutzern mehrmals angefordert werden.

  2. Personalisierte Inhalte für verschiedene Zeiträume zwischenspeichern - Wenn Ihre Site personalisierte Inhalte aufweist, sollten Sie in Erwägung ziehen, Apache Sling Dynamic Includes in Ihrer AEM-Anwendung zu verwenden, um Ajax (asynchrone JavaScript- und XML-Aufrufe auf Browserebene), SSI (Server Side Includes auf Webserverebene) und ESI (Edge-seitige Includes auf CDN-Ebene) für den Zwischenspeicher verschiedener Teile der Seite zu nutzen für verschiedene Zeiträume.

  3. Löschen Sie nie den Dispatcher-Cache auf einem Live-Dispatcher - Wenn eine Dispatcher Live-Inhalte bereitstellt und Sie den Cache löschen, führt dies zu einer massiven Flut von Anforderungen, die an AEM zurückgesendet werden.  Aus diesem Grund sollte der Dispatcher-Cache nie in einem Live-Dispatcher gelöscht werden.

  4. Bereiten Sie den Cache auf : Bevor Sie den Dispatcher-Cache löschen, ziehen Sie den Dispatcher aus dem Lastenausgleich, löschen Sie den Cache und führen Sie dann ein Webcrawler-Tool aus, um Dateien in der Dispatcher zwischenzuspeichern, bevor Sie ihn in den Lastenausgleich einfügen.

  5. Cache-Fehlerseiten - Nutzen Sie die Anweisung DispatcherPassError 1 (Apache Web Server-spezifisch) , um Fehlerseiten wie 404 s aus dem Dispatcher-Cache bereitzustellen.

  6. GZip komprimiert alle Dateitypen mit Ausnahme der vorkomprimierten Dateitypen - In Apache-Webserver kann mod_deflate verwendet werden. Stellen Sie jedoch sicher, dass Vary: User-Agent header nicht festgelegt ist.  Verwenden Sie in Microsoft IIS Dynamische Komprimierung.

    Apache-Konfigurationsbeispiel (Angabe nur bestimmter Inhaltstypen, um vorkomprimierte Dateitypen zu vermeiden):

    AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript

  7. Aktivieren Sie /serveStaleOnError in der /cache-Konfiguration - Servieren Sie die alte Cache-Datei, wenn AEM Instanzen Fehler bereitstellen.

  8. Fügen Sie /gracePeriod zur /cache-Konfiguration hinzu - Definieren Sie die Anzahl der Sekunden, nach denen eine veraltete, automatisch invalidierte Ressource nach dem letzten Inhaltsveröffentlichungsereignis ("Aktivierung") weiterhin aus dem Cache bereitgestellt werden kann.  Dadurch wird die Anzahl der Anfragen reduziert, die während einer umfangreichen Inhaltsveröffentlichungsaktivität wie z. B. „Baumstrukturaktivierung“an die Veröffentlichungsinstanzen zurückgesendet werden.

  9. Fügen Sie Regeln zu /ignoreUrlParams hinzu - Ignorieren Sie Abfragezeichenfolgenparameter, die von der Anwendung nicht benötigt oder verwendet werden.  Dies ermöglicht das Zwischenspeichern von URLs, selbst wenn eine Abfragezeichenfolge vorhanden ist.

  10. Cache-Control- und Last-Modified-Response-Header zwischenspeichern - Verwenden Sie die Konfiguration /headers , um die HTTP-Antwort-Header Cache-Control und Last-Modified (und/oder den Header ETag zwischenzuspeichern, wenn Sie sie von AEM senden).  Dies hilft bei der Vereinfachung und Optimierung des Caching auf CDN- und Browser-Ebene.  Durch das Caching dieser Header werden die Header nur von AEM festgelegt, nicht vom Webserver selbst.  Beachten Sie, dass Sie in diesem Fall mit dem Senden der Header aus Ihrer AEM App beginnen müssen.

  11. Inhalt so lange wie möglich zwischenspeichern und reduzieren Anforderungen, die zurück zu AEM gehen - Optimieren Sie Flush-Anfragen, indem Sie die Flush-Flush-Konfiguration für alle Flush-Agenten aktivieren. Siehe folgenden Abschnitt mit dem Titel Erneutes Abrufen von Dispatcher Flush. Oder verwenden Sie /enableTTL und legen Sie den Header Cache-Control: max-age=… so fest, dass Dateien so lange wie möglich zwischengespeichert werden.  Einzelheiten zu diesem Thema siehe unten.

Verwenden von TTLs

Ab Dispatcher-Version 4.1.11 kann /enableTTL 1 in jeder Dateikonfiguration festgelegt werden.  Durch diese Einstellung berücksichtigt Dispatcher die im HTTP Cache-Control-Antwortheader festgelegten Cache-Abläufe.  Das heißt, die Dispatcher funktioniert ähnlich wie ein CDN, bei dem die primäre Form der Cache-Invalidierung bei Ablauf von Dateien auftritt.  Nachdem Sie dies implementiert haben und beginnen, Cache-Control: max-age=… zu senden.  für alle Antworten von AEM können Sie Ihre Dispatcher-Flush-Agenten in den Veröffentlichungsinstanzen sicher deaktivieren.

Nachdem Sie die Flush-Agenten in den Veröffentlichungsinstanzen deaktiviert haben, können Sie den Dispatcher-Cache möglicherweise dennoch leeren.  In diesem Fall können Sie die ACS Commons – Dispatcher-Lösch-Benutzeroberfläche verwenden.  Dieses Tool ist auf der Autoreninstanz installiert.  Es bietet Benutzern eine Benutzeroberfläche, in der sie manuelle Cache-Löschanfragen ausführen können.

I. Schritte zur Aktivierung von TTL („Time to Live“ oder Ablaufdatum)-ähnlichen Invalidierungen:

  1. Ändern Sie den Quellcode in der AEM Anwendung so, dass Cache-Control header und Last-Modified für alle Anforderungen gesendet werden, für die er noch nicht festgelegt ist.
  2. Installieren Sie Dispatcher 4.1.11 oder höher.
  3. Legen Sie /enableTTL 1 in jeder Farm-Konfiguration der Site fest.
  4. Legen Sie die Konfiguration /headers fest, um die Header Cache-Control und Last-Modified zwischenzuspeichern.
  5. Starten Sie den Webserver neu.

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

Die Dispatcher verwendet jetzt den Header Cache-Control , um die Invalidierung der Cachedateien zu steuern.  Da dies der Fall ist, ist das Bereinigen von Dispatcher aus den Veröffentlichungsinstanzen nicht mehr erforderlich.

  1. Wechseln Sie in jeder Veröffentlichungsinstanz zu /etc/replication/agents.publish.html .
  2. Gehen Sie zur Konfiguration jedes Löschagenten und deaktivieren Sie den Agenten.

III. Zulassen manueller Dispatcher-Flush-Anfragen von der Autoreninstanz:

Nachdem die Flush-Agenten deaktiviert sind, verlassen Sie sich vollständig auf den Header Cache-Control , um zu steuern, wann der Inhalt auf dem Dispatcher aktualisiert wird.  Sie können Benutzern weiterhin erlauben, manuelle Leeren des Dispatcher-Caches auszuführen:

  1. Installieren Sie die ACS Commons – Dispatcher-Lösch-Benutzeroberfläche auf der Autoreninstanz.
  2. Konfigurieren Sie die Löschagenten in der Autoreninstanz.
  3. Legen Sie in jeder Agentenkonfiguration Trigger => fest.   Option "Standard ignorieren" aktivieren. Diese Option bewirkt, dass die Löschagenten ignorieren, wenn Benutzer in der AEM-Benutzeroberfläche auf Veröffentlichen (aufheben) oder Aktivieren (deaktivieren) klicken.

Dispatcher Flush erneut abrufen

Um die Dispatcher-Flush-Anfragen zu optimieren, sollte für alle Dispatcher-Flush-Agenten eine Funktion namens "Flush-Flush-Neuerung"aktiviert sein.

Um das erneute Abrufen des Dispatcher-Flush zu aktivieren, gehen Sie wie folgt vor:

  1. Navigieren Sie zu  http://aemhost:port/crx/packmgr/index.jsp  und melden Sie sich als Administrator an.

  2. Laden Sie hier das Paket herunter.

  3. Laden Sie das Paket hoch und installieren Sie es im Package Manager.

  4. Gehen Sie zur Konfiguration Ihres Dispatcher Flush-Agenten . Beispiel:  /etc/replication/agents.author/flush.html

  5. Klicken Sie auf Bearbeiten.

  6. Legen Sie die folgenden Einstellungen fest.

    • Serialisierungstyp  =  Neuabruf der Dispatcher-Leerung
    • Extended =>   HTTP-Methode = POST

  7. Klicken Sie auf Speichern.

Hinweis - Das oben installierte Paket ist nur ein einfaches Beispiel.  Um den erneuten Abruf der Leerung anzupassen und zu optimieren, können Sie die Liste der gesendeten URIs ändern.  Der Code ist Open Source und kann hier gefunden werden.  Der Code fügt dem Anfragetext eine Liste von URIs als Parameter hinzu, die Dispatcher mitteilen, welche Pfade erneut abgerufen werden sollen.  Sie können je nach Ihren Anwendungsanforderungen weitere Pfade hinzufügen, um die Caching-Funktionen Ihrer Site zu optimieren.

Detaillierte Erläuterung des erneuten Abrufs der Leerung

Normalerweise funktioniert ein Dispatcher-Flush durch das Löschen von Dateien:

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

Da Dateien in Schritt 2 gelöscht werden, werden beim nächsten Anfordern einer Datei wie /content/foo.html oder /content/foo.json, während die Datei "erneut abgerufen"wird, auch nachfolgende Anforderungen für dieselbe Datei an die Veröffentlichungsinstanzen gesendet, bis die Datei zwischengespeichert wird.  Bei langsamen Antworten oder Seiten mit hohem Traffic-Aufkommen wie Homepages kann dies zu Überflutungen der Veröffentlichungsinstanzebene führen.

Um dieses Problem zu beheben, aktivieren Sie eine Funktion des Dispatcher, die als Neuabruf bezeichnet wird.  Mit dieser Funktion können Sie eine Liste von URIs senden, die die Dispatcher proaktiv "erneut abrufen"und anstelle des Löschens ersetzen soll.

Unter 22:41-27:05 in dieser Präsentationsaufzeichnung finden Sie eine Demonstration der Funktionsweise und der Konfiguration des Systems.

recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f