Dispatcher-Versionen sind unabhängig von AEM. Möglicherweise wurden Sie von der Dokumentation zu einer früheren AEM-Version zu dieser Seite weitergeleitet.
Der Dispatcher ist das Tool zum Zwischenspeichern und Lastenausgleich von Adobe Experience Manager, das mit einem Webserver der Unternehmensklasse verwendet wird.
Der Prozess für die Bereitstellung des Dispatchers ist unabhängig vom Webserver und der gewählten Betriebssystemplattform:
So erhalten Sie ein besseres Verständnis darüber, wie der Dispatcher mit AEM funktioniert:
Ziehen Sie bei Bedarf die folgenden Ressourcen hinzu:
Dispatcher wird am häufigsten zum Zwischenspeichern von Antworten aus einer AEM-Veröffentlichungsinstanz verwendet, um die Reaktionsfähigkeit und Sicherheit einer öffentlich zugänglichen veröffentlichten Website zu erhöhen. Diese Anwendung steht im Mittelpunkt des Themas.
Mit dem Dispatcher kann jedoch auch die Reaktionsgeschwindigkeit der Autoreninstanz gesteigert werden, besonders wenn viele Benutzer Ihre Website bearbeiten und aktualisieren. Weitere Informationen zu diesem speziellen Fall finden Sie unten unter Verwenden eines Dispatchers mit einem Autorenserver.
Es gibt zwei grundlegende Ansätze zum Veröffentlichen im Web:
Mit dem Dispatcher können Sie eine Umgebung realisieren, die gleichzeitig schnell und dynamisch ist. Der Dispatcher funktioniert als Teil eines statischen HTML-Servers wie Apache mit folgendem Ziel:
Dies bedeutet:
statische Inhalte wird mit derselben Geschwindigkeit und Leichtigkeit wie auf einem statischen Webserver verarbeitet. Außerdem können Sie die Verwaltungs- und Sicherheitstools verwenden, die für Ihre statischen Webserver verfügbar sind.
Dynamische Inhalte werden nach Bedarf generiert, ohne das System mehr als absolut notwendig zu verlangsamen.
Der Dispatcher umfasst Mechanismen zum Generieren und Aktualisieren von statischem HTML auf Grundlage der Inhalte der dynamischen Website. Sie können detailliert angeben, welche Dokumente als statische Dateien gespeichert werden sollen und welche immer dynamisch generiert werden.
In diesem Abschnitt werden die Grundlagen dieses Prozesses erläutert.
Ein statischer Webserver, wie z. B. Apache oder IIS, stellt statische HTML-Dateien für die Besucher Ihrer Website bereit. Statische Seiten werden einmal erstellt, sodass für jede Anforderung derselbe Inhalt bereitgestellt wird.
Dieser Prozess ist einfach und effizient. Wenn ein Besucher eine Datei wie eine HTML-Seite anfordert, wird die Datei direkt aus dem Speicher übernommen. Im schlimmsten Fall wird es von der lokalen Festplatte gelesen. Statische Webserver sind schon seit geraumer Zeit verfügbar, sodass es eine breite Palette von Tools für Verwaltung und Sicherheitsmanagement gibt und sie gut in Netzwerkinfrastrukturen integriert sind.
Wenn Sie ein CMS (Content Management Server) wie AEM verwenden, verarbeitet eine erweiterte Layout-Engine die Anforderung eines Besuchers. Die Engine liest Inhalte aus einem Repository, das in Kombination mit Stilen, Formaten und Zugriffsrechten den Inhalt in ein Dokument umwandelt, das auf die Bedürfnisse und Rechte eines Besuchers zugeschnitten ist.
Dieser Workflow ermöglicht die Erstellung umfassenderer, dynamischer Inhalte, wodurch die Flexibilität und Funktionalität Ihrer Website gesteigert wird. Allerdings ist für die Layout-Engine mehr Verarbeitungsleistung als für einen statischen Server erforderlich. Daher ist dieses Setup für Verzögerungen anfällig, wenn viele Besucher das System verwenden.
Das Cache-Verzeichnis Zum Zwischenspeichern nutzt das Dispatcher-Modul die Fähigkeit des Webservers, statische Inhalte bereitzustellen. Der Dispatcher legt die zwischengespeicherten Dokumente im Basisverzeichnis des Webservers ab.
Wenn die Konfiguration für das Zwischenspeichern von HTTP-Headern fehlt, speichert der Dispatcher nur den HTML-Code der Seite. Die HTTP-Header werden nicht gespeichert. Dieses Szenario kann bei der Verwendung verschiedener Kodierungen auf Ihrer Website problematisch sein, da diese Seiten möglicherweise verloren gehen. Informationen zum Aktivieren der HTTP-Header-Zwischenspeicherung finden Sie unter Konfigurieren des Dispatcher-Cache.
Das Suchen des Dokumentenstamms Ihres Webservers auf NAS-Speichern führt zu einer verringerten Leistung. Wenn ein Dokumentenstamm auf NAS von mehreren Webservern gemeinsam genutzt wird, kann es bei Replikationsaktionen zu zeitweiligen Sperren kommen.
Der Dispatcher speichert das zwischengespeicherte Dokument in einer Struktur, die der angeforderten URL entspricht.
Für die Länge des Dateinamens kann es Einschränkungen auf Betriebssystemebene geben. Das heißt, wenn Sie eine URL mit zahlreichen Selektoren haben.
Der Dispatcher verwendet zwei Hauptverfahren zum Aktualisieren des zwischengespeicherten Inhalts, wenn Änderungen an der Website vorgenommen werden.
Bei einer Inhaltsaktualisierung werden ein oder mehrere AEM-Dokumente geändert. AEM sendet eine Syndizierungsanforderung an den Dispatcher, der den Cache entsprechend aktualisiert:
Beachten Sie die folgenden Punkte:
Bei der automatischen Invalidierung werden Teile des Caches automatisch ungültig gemacht – ohne Dateien physisch zu löschen. Bei jeder Inhaltsaktualisierung wird die sogenannte Statfile bearbeitet, sodass der Zeitstempel den Zeitpunkt der letzten Aktualisierung angibt.
Der Dispatcher verfügt über eine Liste der Dateien, für die die automatische Invalidierung gilt. Wenn ein Dokument aus dieser Liste angefordert wird, vergleicht der Dispatcher das Datum des zwischengespeicherten Dokuments mit dem Zeitstempel der Statfile:
Auch hier sollten bestimmte Punkte beachtet werden:
Sie können definieren, welche Dokumente der Dispatcher in der Konfigurationsdatei zwischenspeichert. Der Dispatcher überprüft die Anforderung anhand der Liste der Dokumente, die zwischengespeichert werden können. Wenn das Dokument nicht in dieser Liste enthalten ist, fragt der Dispatcher das Dokument in der AEM-Instanz ab.
Der Dispatcher ruft das Dokument in den folgenden Fällen immer direkt aus der AEM-Instanz ab:
?
". Dieses Szenario zeigt normalerweise eine dynamische Seite an, z. B. ein Suchergebnis, die nicht zwischengespeichert werden muss.Die Methoden GET oder HEAD (für den HTTP-Header) können vom Dispatcher zwischengespeichert werden. Weitere Informationen zum Zwischenspeichern von Antwortheadern finden Sie im Abschnitt Zwischenspeichern von HTTP-Antwortheadern.
Der Dispatcher speichert die zwischengespeicherten Dateien auf dem Webserver, als wären sie Teil einer statischen Website. Wenn ein Benutzer ein zwischenspeicherbares Dokument anfordert, prüft der Dispatcher, ob dieses Dokument im Dateisystem des Webservers vorhanden ist:
Um festzustellen, ob ein Dokument aktuell ist, führt der Dispatcher zwei Schritte aus:
Dokumente ohne automatische Invalidierung bleiben im Cache, bis sie physisch gelöscht werden. Beispielsweise durch eine Inhaltsaktualisierung auf der Website.
Beim Lastenausgleich wird die Rechenleistung für eine Website auf mehrere Instanzen von AEM verteilt.
Vorteile:
erhöhte Verarbeitungsleistung
In der Praxis bedeutet eine höhere Verarbeitungsleistung, dass der Dispatcher Dokumentanforderungen zwischen mehreren Instanzen von AEM teilt. Da jede Instanz jetzt weniger Dokumente verarbeiten muss, sind die Reaktionszeiten kürzer. Der Dispatcher führt interne Statistiken für jede Dokumentenkategorie, sodass die Anforderungen geschätzt und die Abfragen effizient aufgeteilt werden können.
Verbesserte Fail-Safe-Abdeckung
Wenn der Dispatcher keine Antworten von einer Instanz erhält, werden Anforderungen automatisch an eine der anderen Instanzen weitergeleitet. Wenn eine Instanz nicht mehr verfügbar ist, ist die einzige Auswirkung eine Verlangsamung der Site, proportional zur verlorenen Rechenleistung. Alle Dienste werden jedoch fortgesetzt.
Sie können auch verschiedene Websites auf demselben statischen Webserver verwalten.
Während die Auslastung durch den Lastenausgleich effizient verteilt wird, wird sie durch die Zwischenspeicherung reduziert. Daher sollten Sie das Zwischenspeichern optimieren und die Gesamtauslastung reduzieren, bevor Sie den Lastenausgleich einrichten. Durch eine optimal konfigurierte Zwischenspeicherung kann die Leistung des Lastenausgleichs gesteigert oder der Lastausgleich überflüssig gemacht werden.
Während ein einzelner Dispatcher die Kapazität der verfügbaren Veröffentlichungsinstanzen überlasten kann, kann es bei einigen seltenen Anwendungen sinnvoll sein, auch die Last zwischen zwei Dispatcher-Instanzen auszugleichen. Konfigurationen mit mehreren Dispatchern müssen sorgfältig geprüft werden, da ein zusätzlicher Dispatcher die Last auf den verfügbaren Veröffentlichungsinstanzen erhöhen und die Leistung in den meisten Anwendungen leicht verringern kann.
Der Dispatcher führt interne Statistiken dazu, wie schnell die einzelnen AEM-Instanzen Dokumente verarbeiten. Basierend auf diesen Daten schätzt der Dispatcher, welche Instanz die schnellste Reaktionszeit bei der Beantwortung einer Anfrage bereitstellen kann, und reserviert so die erforderliche Berechnungszeit für diese Instanz.
Verschiedene Anforderungstypen können unterschiedliche durchschnittliche Fertigstellungszeiten aufweisen. Daher können Sie vom Dispatcher Dokumentkategorien angeben. Diese Kategorien werden dann bei der Berechnung der Zeitschätzungen berücksichtigt. Sie können beispielsweise zwischen HTML-Seiten und Bildern unterscheiden, da die typischen Antwortzeiten sehr unterschiedlich sein können.
Wenn Sie eine umfangreiche Suchfunktion verwenden, können Sie eine Kategorie für Suchabfragen erstellen. Diese Methode hilft dem Dispatcher dabei, Suchanfragen an die Instanz zu senden, die am schnellsten antwortet. Außerdem wird dadurch verhindert, dass eine langsamere Instanz angehalten wird, wenn sie mehrere "teure"Suchanfragen erhält, während die anderen die "billigeren"Anforderungen erhalten.
Sticky-Verbindungen stellen sicher, dass alle Dokumente für einen Benutzer auf derselben AEM-Instanz erstellt werden. Dieser Punkt ist wichtig, wenn Sie personalisierte Seiten und Sitzungsdaten verwenden. Die Daten werden in der Instanz gespeichert, sodass nachfolgende Anforderungen vom selben Benutzer zu dieser Instanz zurückführen müssen. Andernfalls gehen die Daten verloren.
Da durch Sticky-Verbindungen die Fähigkeit des Dispatchers eingeschränkt wird, die Anforderungen zu optimieren, sollten Sie sie nur bei Bedarf verwenden. Sie können den Ordner angeben, in dem die „Sticky-Dokumente“ gespeichert werden, und so sicherstellen, dass alle Dokumente in diesem Ordner für jeden Benutzer auf derselben Instanz erstellt werden.
Bei den meisten Seiten, die Sticky-Verbindungen verwenden, müssen Sie das Zwischenspeichern deaktivieren. Andernfalls wird die Seite für alle Benutzer gleich angezeigt, unabhängig vom Sitzungsinhalt.
Bei einigen Anwendungen ist es möglich, Sticky-Verbindungen und Zwischenspeichern zu verwenden, zum Beispiel, wenn Sie ein Formular anzeigen, das Daten in die Sitzung schreibt.
In komplexen Umgebungen können Sie mehrere Dispatcher verwenden. Folgende Szenarien sind möglich:
In einem solchen Fall müssen Sie sicherstellen, dass jede Anforderung nur einen Dispatcher durchläuft. Ein Dispatcher verarbeitet keine Anforderungen, die von einem anderen Dispatcher stammen. Stellen Sie daher sicher, dass beide Dispatcher direkt auf die AEM-Website zugreifen.
Ein CDN (Content Delivery Network) wie Akamai Edge Delivery oder Amazon Cloud Front stellt Inhalte von einem Speicherort in der Nähe des Endbenutzers bereit. Dies hat folgende Vorteile:
Als HTTP-Infrastrukturkomponente funktioniert ein CDN ähnlich wie der Dispatcher. Wenn ein CDN-Knoten eine Anforderung erhält, wird die Anforderung nach Möglichkeit aus dem Cache bereitgestellt (die Ressource ist im Cache verfügbar und gültig). Andernfalls wird der nächstgelegene Server kontaktiert, um die Ressource abzurufen und sie ggf. für weitere Anforderungen zwischenzuspeichern.
Welcher Server der nächstgelegene ist, hängt von Ihrem jeweiligen Setup ab. In einem Akamai-Setup kann die Abfrage z. B. den folgenden Pfad durchlaufen:
Normalerweise ist der Dispatcher der nächste Server, der das Dokument aus einem Cache bereitstellt und die an den CDN-Server zurückgegebenen Antwortheader beeinflusst.
Es gibt mehrere Möglichkeiten, zu steuern, wie lange ein CDN eine Ressource zwischenspeichert, bevor sie erneut vom Dispatcher abgerufen wird.
Explizite Konfiguration
Konfigurieren Sie, wie lange bestimmte Ressourcen im Cache des CDN gespeichert werden, je nach MIME-Typ, Erweiterung, Anfragetyp usw.
Ablauf- und Cache-Steuerelemente
Die meisten CDNs berücksichtigen Expires:
und Cache-Control:
HTTP-Header, wenn vom Upstream-Server gesendet. Diese Methode kann beispielsweise mithilfe der mod_expires Apache-Modul.
Manuelle Invalidierung
Durch CDNs können Ressourcen über Webschnittstellen aus dem Cache entfernt werden.
API-basierte Invalidierung
Die meisten CDNs bieten außerdem eine REST- und/oder eine SOAP-API, mit der Ressourcen aus dem Cache entfernt werden können.
In einer typischen AEM-Einrichtung bietet die Konfiguration durch Erweiterung, Pfad oder beides - was über die Punkte 1 und 2 erreicht werden kann - Möglichkeiten, angemessene Caching-Zeiträume für häufig verwendete Ressourcen festzulegen, die sich häufig nicht ändern, wie z. B. Design-Bilder und Client-Bibliotheken. Wenn neue Releases bereitgestellt werden, ist in der Regel eine manuelle Invalidierung erforderlich.
Wenn verwaltete Inhalte mit diesem Verfahren zwischengespeichert werden, bedeutet dies, dass Änderungen am Inhalt für Endbenutzer erst sichtbar sind, wenn die konfigurierte Dauer für die Zwischenspeicherung abgelaufen ist und das Dokument erneut vom Dispatcher abgerufen wird.
Für eine präzisere Kontrolle können Sie mit der API-basierten Invalidierung den Cache eines CDN invalidieren, wenn der Dispatcher-Cache ungültig gemacht wird. Basierend auf der CDNs-API können Sie Ihre ContentBuilder und TransportHandler (wenn die API nicht auf REST basiert) und richten Sie einen Replikationsagenten ein, der diese Teile verwendet, um den Cache des CDN zu invalidieren.
Siehe auch AEM (CQ) Dispatcher-Sicherheit und CDN+Browser-Caching und Aufzeichnung einer Präsentation zu Dispatcher-Caching.
Wenn Sie AEM mit Touch-Benutzeroberfläche, do not Inhalt der Autoreninstanz zwischenspeichern. Wenn die Zwischenspeicherung für die Autoreninstanz aktiviert wurde, müssen Sie sie deaktivieren und den Inhalt des Cache-Ordners löschen. Um die Zwischenspeicherung zu deaktivieren, bearbeiten Sie die author_dispatcher.any
und ändern Sie die /rule
-Eigenschaft der /cache
wie folgt:
/rules
{
/0000
{ /type "deny" /glob "*"}
}
Ein Dispatcher kann vor einer Autoreninstanz verwendet werden, um die Bearbeitungsleistung zu verbessern. Um einen Bearbeitungs-Dispatcher zu konfigurieren, führen Sie die folgenden Schritte aus:
Installieren Sie einen Dispatcher auf einem Webserver (einem Apache- oder IIS-Webserver, siehe Installieren des Dispatchers).
Testen Sie den neu installierten Dispatcher mit einer funktionierenden AEM Veröffentlichungsinstanz. Dadurch wird sichergestellt, dass eine Grundlinie korrekte Installation erreicht wurde.
Stellen Sie dann sicher, dass der Dispatcher über TCP/IP eine Verbindung zur Autoreninstanz herstellen kann.
Beispiel ersetzen dispatcher.any
-Datei mit author_dispatcher.any
-Datei, die mit dem Dispatcher-Download.
Öffnen Sie author_dispatcher.any
in einem Texteditor und nehmen Sie die folgenden Änderungen vor:
/hostname
und /port
des /renders
-Abschnitt, damit sie auf Ihre Autoreninstanz verweisen./docroot
des /cache
-Abschnitt, damit sie auf ein Cache-Verzeichnis verweisen. In diesem Fall verwenden Sie AEM mit Touch-Benutzeroberfläche, siehe die Warnung oben.Löschen Sie alle vorhandenen Dateien im Verzeichnis /cache
> /docroot
, das oben konfiguriert wurde.
Starten Sie den Webserver neu.
Mit den bereitgestellten author_dispatcher.any
Konfiguration, wenn Sie ein CQ5-Feature Pack, Hotfix oder Anwendungs-Code-Paket installieren, das sich auf alle Inhalte unter /libs
oder /apps
müssen Sie die zwischengespeicherten Dateien unter diesen Ordnern im Dispatcher-Cache löschen. Dadurch wird sichergestellt, dass beim nächsten Anfordern die neu aktualisierten Dateien abgerufen werden und nicht die alten zwischengespeicherten Dateien.
Wenn Sie den zuvor konfigurierten Autor-Dispatcher verwendet und eine Dispatcher-Flushing-Agent führen Sie folgende Schritte aus: