Wie kann ich den Dispatcher-Cache optimieren?
Dieser Artikel enthält detaillierte Anweisungen zu den verschiedenen Möglichkeiten, den Dispatcher-Cache zu optimieren. Außerdem werden die Schritte zum Aktivieren von TTL-Invalidierungen („Time to Live“ oder Ablaufdatum), Deaktivieren von Dispatcher-Löschagenten, erneutes Abrufen von Dispatcher-Leerung und andere beschrieben.
Beschreibung description
Umgebung
Adobe Experience Manager
Probleme/Symptome
Dieser Artikel konzentriert sich auf die neuesten Optimierungen in AEM Dispatcher und wie diese am besten genutzt werden können. Der AEM Dispatcher ist ein zwischenspeichernder Reverse-Proxy-Server, der für die Verwendung mit Adobe Experience Manager entwickelt wurde. Es kann als Modul in einer vorhandenen Webserver-Software installiert und ausgeführt werden. Zum Zeitpunkt der Erstellung dieses Artikels wird das Dispatcher-Modul 🔗 auf Apache HTTP Server, Microsoft IIS und iPlanet unterstützt.
Auflösung resolution
Wie funktioniert das Caching in Dispatcher?
Auf der grundlegendsten Ebene ist der AEM-Dispatcher ein Reverse-Proxy, der durch Caching, Cache-Leerung und Cache-Invalidierung funktioniert.
Weitere Informationen zu Dispatcher finden Sie unter den entsprechenden Links:
- Funktionsweise von Dispatcher und Installation.
- In der Dispatcher verfügbare Konfigurationsoptionen.
- Webinar zur Funktionsweise von Dispatcher - Beachten Sie, dass einige Informationen in der Präsentation auf alten Versionen des Dispatchers basieren.
- Gems-Webinarsitzung zu Dispatcher-Funktionen, CDN-Nutzung und Sicherheit.
- Gems-Sitzung zu neuen Funktionen in Dispatcher (nach Version 4.1.9).
Optimieren des Dispatcher-Cache
Im Folgenden finden Sie einige Möglichkeiten, den Dispatcher-Cache zu optimieren:
-
Fast alles zwischenspeichern - Dies bedeutet, dass alle Inhalte zwischengespeichert werden, die von Benutzern mehrmals angefordert werden.
-
Personalisierte Inhalte für verschiedene Zeiträume zwischenspeichern - Wenn Ihre Site personalisierte Inhalte hat, 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.
-
Den Dispatcher-Cache auf einer Live-Dispatcher niemals löschen - Wenn eine Dispatcher Live-Inhalte bereitstellt und Sie den Cache löschen, führt dies zu einer massiven Flut von Anfragen, die an AEM zurückgesendet werden. Aus diesem Grund sollte der Dispatcher-Cache auf einer Live-Dispatcher niemals gelöscht werden.
-
Prime-Cache - Ziehen Sie vor dem Löschen des Dispatcher-Caches den Dispatcher von Ihrem Load-Balancer ab, löschen Sie den Cache und führen Sie dann ein Web-Crawler-Tool aus, um Dateien auf der Dispatcher zwischenzuspeichern, bevor Sie sie auf den Lastenausgleich setzen.
-
Cache-Fehlerseiten - Nutzen Sie die DispatcherPassError 1 (Apache-Webserver-spezifische)-Direktive, um Fehlerseiten wie 404s aus dem Dispatcher-Cache zu liefern.
-
Alle Dateitypen mit Ausnahme der vorkomprimierten mit GZip komprimieren - Im Apache-Webserver könnte mod_deflate verwendet werden, aber stellen Sie sicher, dass Vary: User-Agent header nicht gesetzt 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****
. Aktivieren Sie /serveStaleOnError in der /cache-Konfiguration - Bereitstellung der alten Cache-Datei, wenn AEM-Instanzen Fehler liefern.. /gracePeriod zur /cache-Konfiguration hinzufügen - Definiert die Anzahl der Sekunden, die eine veraltete, automatisch für ungültig erklärte Ressource nach dem letzten Ereignis der Inhaltsveröffentlichung („Aktivierung„) noch aus dem Cache bedient werden darf. 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.. Regeln zu /ignoreUrlParams hinzufügen - Ignoriert 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.. Cache-Control- und Last-Modified-Antwort-Header zwischenspeichern - Verwenden Sie die /headers-Konfiguration, um die HTTP-Antwort-Header Cache-Control und Last-Modified (und/oder ETag-Header, wenn Sie sie über AEM senden) zwischenzuspeichern. 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 damit beginnen müssen, die Header aus Ihrem AEM-Programm zu senden.. Inhalte so lange wie möglich zwischenspeichern und Reduzieren von Anfragen, die zurück an AEM gehen - Optimieren Sie Löschanfragen, indem Sie das Refetching Flush für alle Löschagenten aktivieren. Siehe folgenden Abschnitt mit dem Titel Neuabruf der Dispatcher-Leerung. Oder verwenden Sie /enableTTL und legen Sie Cache-Control: max-age=…-Header fest, um Dateien so lange wie möglich zwischenzuspeichern. Einzelheiten zu diesem Thema siehe unten.
****Verwenden von TTLs**Ab Dispatcher Version 4.1.11 kann /enableTTL 1 in jeder Dateikonfiguration festgelegt werden. Diese Einstellung bewirkt, dass die Dispatcher die im Antwort-Header der HTTP-Cache-Steuerung festgelegten Cache-Ablaufzeiten berücksichtigt. Mit anderen Worten, die Dispatcher funktioniert ähnlich wie ein CDN, bei dem die primäre Form der Cache-Invalidierung auftritt, wenn Dateien ablaufen. Sobald Sie dies implementiert haben und beginnen, Cache-Control: max-age=… Für alle Antworten von AEM können Sie Ihre Dispatcher-Löschagenten in den Veröffentlichungsinstanzen sicher deaktivieren.Nachdem Sie die Löschagenten in den Veröffentlichungsinstanzen deaktiviert haben, möchten Sie möglicherweise weiterhin den Dispatcher-Cache leeren können. 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 Quell-Code in der AEM-Anwendung, um Cache-Control-Header und Last-Modified für alle Anfragen zu senden, für die er nicht bereits festgelegt ist.
2) Installieren Sie Dispatcher 4.1.11 oder höher.
3) Setzen Sie /enableTTL 1 in einer beliebigen Farm-Konfiguration der Website.
4) Legen Sie die /headers- fest, um die Header Cache-Control und Last-Modified zwischenzuspeichern.
5) Starten Sie den Webserver neu.**II. Deaktivieren Sie Dispatcher-Löschagenten in den Veröffentlichungsinstanzen:**Die Dispatcher verwendet jetzt den Cache-Control-Header, um die Invalidierung der Cache-Dateien zu steuern. Da dies der Fall ist, ist eine Dispatcher-Leerung von den Veröffentlichungsinstanzen aus nicht mehr erforderlich.1) Navigieren 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. Lassen Sie manuelle Dispatcher-Löschanfragen von der Autoreninstanz aus zu:Da die Löschagenten nun deaktiviert sind, müssen Sie sich ganz auf den Header Cache-Control verlassen, um zu steuern, wann die Inhalte auf dem Dispatcher aktualisiert werden. Sie können Benutzern weiterhin erlauben, manuelle Leerungen 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>
Standard ignorieren Option auf „Aktiviert“. Diese Option bewirkt, dass die Löschagenten ignorieren, wenn Benutzer in der AEM-Benutzeroberfläche auf Veröffentlichen (aufheben) oder Aktivieren (deaktivieren) klicken.Dispatcher-Leerung wird erneut abgerufen**Um die Dispatcher-Löschanfragen zu optimieren, sollte für alle Dispatcher-Löschagenten eine Funktion namens „Refetching Flush“ aktiviert sein.Gehen Sie wie folgt vor, um das erneute Abrufen der Dispatcher-Leerung zu aktivieren:1) Navigieren Sie zu http://aemhost:port/crx/packmgr/index.jsp und melden Sie sich als Administrator an.
-
Laden Sie hier das Paket herunter.
-
Laden Sie das Paket hoch und installieren Sie es in Package Manager.
-
Gehen Sie zur Konfiguration Ihres Dispatcher Flush-Agenten. Beispiel: /etc/replication/agents.author/flush.html
-
Klicken Sie auf Bearbeiten.
-
Legen Sie die folgenden Einstellungen fest.
- Serialisierungstyp = Neuabruf der Dispatcher-Leerung
- Erweitert =
>
HTTP-Methode = POST
-
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 Anwendungsanforderungen weitere Pfade hinzufügen, um die Caching-Funktionen Ihrer Site zu optimieren.**Detaillierte Erklärung zum erneuten Abrufen der Leerung**Normalerweise funktioniert eine Dispatcher-Leerung durch Löschen von Dateien:1) .stat Datei(en) anfassen
-
Löschen Sie /content/foo.*
-
Löschen Sie /content/foo/_jcr_contentDa die Dateien in Schritt 2 gelöscht werden, würden bei der nächsten Anfrage eines Benutzers nach einer Datei wie /content/foo.html oder /content/foo.json, während die Datei „erneut abgerufen“ wird, nachfolgende Anfragen nach derselben Datei ebenfalls an die Veröffentlichungsinstanzen gesendet, bis die Datei zwischengespeichert ist. 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 der Dispatcher, die als erneuter Abruf bezeichnet wird. Mit dieser Funktion können Sie eine Liste von URIs senden, die die Dispatcher proaktiv „erneut abrufen“ und ersetzen soll, anstatt sie zu löschen.Unter 22:41-27:05 in dieser Präsentationsaufzeichnung finden Sie eine Demonstration der Funktionsweise und der Konfiguration des Systems.**