Dokumentation

Wie kann der Dispatcher-Cache optimiert werden?

Last update: Wed Jun 19 2024 00:00:00 GMT+0000 (Coordinated Universal Time)

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

Beschreibung description

Umgebung

Adobe Experience Manager

Probleme/Symptome

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

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 zum Dispatcher finden Sie unter den entsprechenden Links .

  1. Funktionsweise des Dispatchers und Installation.
  2. Im Dispatcher verfügbare Konfigurationsoptionen.
  3. Webinar zur Funktionsweise des Dispatchers - 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 neuen Funktionen in Dispatcher (nach Version 4.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 enthält, sollten Sie Apache Sling Dynamic Includes in Ihrer AEM Anwendung verwenden, um Ajax (asynchrone JavaScript- und XML-Aufrufe auf Browserebene), SSI (Server Side Includes auf Webserverebene) und ESI (Edge-side Includes auf CDN-Ebene) zu nutzen, um verschiedene Teile der Seite für verschiedene Zeiträume zwischenzuspeichern.

  3. Löschen Sie nie 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 Anforderungen, die an AEM zurückgesendet werden.  Aus diesem Grund sollte der Dispatcher-Cache nie in einem Live-Dispatcher gelöscht werden.

  4. Leeren des Cache  - Ziehen Sie vor dem Löschen des Dispatcher-Caches den Dispatcher aus dem Lastenausgleich, löschen Sie den Cache und führen Sie dann ein Web-Crawler-Tool aus, um Dateien im Dispatcher zwischenzuspeichern, bevor Sie ihn in den Lastenausgleich einfügen.

  5. Cache-Fehlerseiten  - Nutzen Sie die DispatcherPassError 1 (Apache Web Server-spezifische) Anweisung zur Bereitstellung von Fehlerseiten wie 404 s aus dem Dispatcher-Cache.

  6. GZip komprimiert alle Dateitypen mit Ausnahme der vorkomprimierten  - auf dem Apache-Webserver, 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 /serveStaleOnError   in der /cache-Konfiguration - Servieren Sie die alte Cachedatei, wenn AEM Instanzen Fehler bereitstellen.

  8. Hinzufügen /gracePeriod   zur /cache-Konfiguration - Definieren Sie die Anzahl der Sekunden, in denen eine veraltete, automatisch invalidierte Ressource nach dem letzten Ereignis zur Inhaltsveröffentlichung ("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. Hinzufügen von Regeln zu /ignoreUrlParams  - Ignorieren Sie Abfragezeichenfolgen-Parameter, 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-Antwort-Header zwischenspeichern  - Verwenden Sie die  /headers  Konfiguration zum Zwischenspeichern der HTTP-Antwortheader  Cache-Control  und  Last-Modified  (und/oder  ETag  -Kopfzeile, 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 von Anforderungen, die zurück an AEM gehen  - Optimieren Sie Flush-Anfragen, indem Sie die Flush-Konfiguration für alle Flush-Agenten aktivieren. Siehe den folgenden Abschnitt mit dem Titel Neuabruf des Dispatcher-Flush. Oder verwenden  /enableTTL  und  Cache-Control: max-age=…  -Kopfzeile, um Dateien so lange wie möglich zwischenzuspeichern.  Einzelheiten zu diesem Thema siehe unten.

Verwenden von TTLs

Ab Dispatcher-Version 4.1.11 gilt Folgendes: /enableTTL 1 kann in jeder beliebigen Dateikonfiguration festgelegt werden.  Durch diese Einstellung berücksichtigt der Dispatcher die im HTTP Cache-Control-Antwortheader festgelegten Cache-Abläufe.  Mit anderen Worten, der Dispatcher funktioniert ähnlich wie ein CDN, bei dem die primäre Form der Cache-Invalidierung auftritt, wenn Dateien ablaufen.  Sobald Sie dies implementieren und mit dem Senden beginnen  Cache-Control: max-age=…  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. Quellcode in der AEM Anwendung zum Senden ändern  Cache-Control  -Kopfzeile und  Last-Modified  für alle Anforderungen, für die sie noch nicht festgelegt ist.
  2. Installieren Sie Dispatcher 4.1.11 oder höher.
  3. Satz  /enableTTL 1  in jeder Farm-Konfiguration der Site.
  4. Legen Sie die  /headers  Konfiguration zum Zwischenspeichern der  Cache-Control  und  Last-Modified  Kopfzeilen.
  5. Starten Sie den Webserver neu.

II. Deaktivieren Sie die Dispatcher-Flush-Agenten in den Veröffentlichungsinstanzen:

Der Dispatcher verwendet jetzt den Header Cache-Control , um die Invalidierung der Cachedateien zu steuern.  Da dies der Fall ist, ist das Leeren des Dispatchers 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 ausschließlich auf die  Cache-Control  -Kopfzeile, 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  =>   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.

Neuabruf des Dispatcher-Flush

Um die Flush-Anfragen des Dispatchers zu optimieren, sollten alle Dispatcher-Flush-Agenten über eine Funktion verfügen, die als Flush-Flush-Neuberechnung bezeichnet wird.

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. Wechseln Sie zur Konfiguration des 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
    • Erweitert  =>   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 dem 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 von Flush

Normalerweise funktioniert ein Dispatcher-Flush durch 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 Dispatchers, die "Neuabruf"heißt.  Mit dieser Funktion können Sie eine Liste von URIs senden, die der Dispatcher proaktiv "erneut abrufen"und ersetzen soll, anstatt zu löschen.

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