Adobe Managed Services Dispatcher Flushing

Beschreibung description

Umgebung
Experience Manager

Problem/Symptome
In diesem Dokument wird erläutert, wie das Leeren erfolgt, und der Mechanismus erläutert, der das Leeren und Invalidieren des Cache ausführt.

Funktionsweise
Reihenfolge der Vorgänge

Der typische Workflow wird am besten beschrieben, wenn Inhaltsautoren eine Seite aktivieren. Wenn der Herausgeber den neuen Inhalt erhält, wird eine Leerungsanfrage an den Dispatcher Trigger, wie im folgenden Diagramm dargestellt:

Diese Verkettung von Ereignissen macht deutlich, dass wir Elemente nur dann löschen, wenn sie neu sind oder sich geändert haben.  Dadurch wird sichergestellt, dass der Inhalt vor dem Leeren des Caches beim Herausgeber eingegangen ist, um Race-Bedingungen zu vermeiden, bei denen das Leeren auftreten könnte, bevor die Änderungen vom Herausgeber übernommen werden können.

Replikationsagenten

Beim Autor gibt es einen Replikationsagenten, der so konfiguriert ist, dass auf den Herausgeber verwiesen wird, dass der Trigger die Datei und alle Abhängigkeiten an den Herausgeber sendet, wenn etwas aktiviert wird.

Wenn der Herausgeber die Datei erhält, hat er einen Replikationsagenten, der so konfiguriert ist, dass er auf den Dispatcher verweist, der beim Empfang des Ereignisses Trigger wird.  Anschließend wird eine Leerungsanfrage serialisiert und an den Dispatcher gesendet.

AUTORREPLIKATIONSAGENTEN

Im Folgenden finden Sie einige Screenshots eines konfigurierten standardmäßigen Replikationsagenten

Es gibt in der Regel 1 oder 2 Replikationsagenten, die auf dem Autor für jeden Herausgeber konfiguriert sind, an den sie Inhalte replizieren.

Der erste ist der standardmäßige Replikationsagent, der Aktivierungen von Inhalten überträgt.

Der zweite ist der umgekehrte Agent.  Dies ist optional und ist so eingerichtet, dass im Postausgang jedes Herausgebers geprüft wird, ob neuer Inhalt zum Aufrufen an den Autor als Rückwärtsreplikationsaktivität vorhanden ist.

VERÖFFENTLICHUNGS-REPLIKATIONSAGENTEN

Im Folgenden finden Sie ein Beispiel für Screenshots eines konfigurierten standardmäßigen Flush-Replikationsagenten

DISPATCHER-FLUSH-REPLIKATION, DIE VIRTUELLEN HOST ERHÄLT

Das Dispatcher-Modul sucht nach bestimmten Headern, um zu erfahren, wann eine POST-Anfrage an AEM Rendering übergeben werden soll oder ob es sich um eine serialisierte Flush-Anfrage handelt, die vom Dispatcher-Handler selbst verarbeitet werden muss.  Im Folgenden finden Sie einen Screenshot der Konfigurationsseite mit den folgenden Werten:

Auf der Seite mit den Standardeinstellungen wird die  Serialisierungstyp  as  Dispatcher Flush  und legt die Fehlerstufe fest

Auf der Registerkarte Transport können Sie sehen, wie der URI so festgelegt ist, dass er auf die IP-Adresse des Dispatchers verweist, der die Flush-Anfragen erhält.  Der Pfad /dispatcher/invalidate.cache zeigt nicht an, wie das Modul feststellt, ob es sich um einen Leerlauf handelt. Es ist nur ein offensichtlicher Endpunkt, den Sie im Zugriffsprotokoll sehen können, um festzustellen, ob es sich um eine Leerungsanfrage handelt.  Auf der Registerkarte "Erweitert"werden die vorhandenen Elemente erläutert, um zu qualifizieren, dass es sich um eine Leerungsanfrage an das Dispatcher-Modul handelt.

Die HTTP-Methode für Flush-Anfragen ist nur eine GET-Anfrage mit einigen speziellen Anfrage-Headern:

Auf dem Tab Trigger werden wir die umschalteten Trigger, die wir verwenden, und deren Eigenschaften zur Kenntnis nehmen.

Wenn wir uns nun ansehen, wie eine typische Flush-Anfrage in Form eines curl-Befehls aussieht

In diesem Beispiel würde der Pfad /content/dam geleert, indem die STAT-Datei in diesem Verzeichnis aktualisiert würde.

Die STAT-Datei

Der Flushing-Mechanismus ist einfach und wir möchten die Bedeutung der  .stat  -Dateien, die im Basisverzeichnis generiert werden, in dem die Cache-Dateien erstellt werden.

In den Dateien .vhost und _farm.any konfigurieren wir eine Basisstammanweisung, um anzugeben, wo sich der Cache befindet und wo Dateien gespeichert/bereitgestellt werden sollen, wenn eine Anfrage von einem Endbenutzer eingeht.

Wenn Sie den folgenden Befehl auf Ihrem Dispatcher-Server ausführen würden, würden Sie mit dem Suchen von STAT-Dateien beginnen

Hier ist ein Diagramm, wie diese Dateistruktur aussehen wird, wenn Sie Elemente im Cache haben und eine Leerungsanfrage vom Dispatcher-Modul gesendet und verarbeitet wurde.

STAT-DATEIEBENE

Beachten Sie, dass in jedem Verzeichnis eine STAT-Datei vorhanden war. Dies ist ein Hinweis darauf, dass eine Leerung aufgetreten ist.  Im obigen Beispiel wird die  statfilelevel  festgelegt wurde auf  3  in der entsprechenden Farm-Konfigurationsdatei.

Die Einstellung statfilelevel gibt an, wie viele Ordner tief das Modul durchläuft und eine STAT-Datei aktualisiert.  Die STAT-Datei ist leer, es handelt sich lediglich um einen Dateinamen mit einem Datenstamp. Sie kann sogar manuell erstellt werden, aber den Touch-Befehl auf der Befehlszeile des Dispatcher-Servers ausführen.

Wenn die Einstellung für die Stat-Dateiebene zu hoch eingestellt ist, durchläuft jede Leerungsanfrage die Verzeichnisstruktur und ändert Stat-Dateien.  Dies kann zu einem großen Leistungseinbruch bei großen Cache-Bäumen werden und sich auf die Gesamtleistung Ihres Dispatchers auswirken.

Wenn Sie diese Dateiebene zu niedrig festlegen, kann eine Leerungsanfrage dazu führen, dass mehr gelöscht wird, als beabsichtigt war. Dies würde wiederum dazu führen, dass der Cache mit weniger Anfragen, die aus dem Cache bedient werden, häufiger überlastet wird, und Leistungsprobleme verursachen.

Hinweis:

Legen Sie die statfilelevel-Ebene auf einer vernünftigen Ebene fest. Schauen Sie sich Ihre Ordnerstruktur an und stellen Sie sicher, dass sie so eingerichtet ist, dass knappe Leerungen möglich sind, ohne zu viele Verzeichnisse durchlaufen zu müssen. Testen Sie es und stellen Sie sicher, dass es Ihren Anforderungen während eines Leistungstests des Systems entspricht.

Ein gutes Beispiel ist eine Site, die Sprachen unterstützt. Der typische Inhaltsstrukturbaum würde die folgenden Verzeichnisse aufweisen

/content/brand1/en/us/

Verwenden Sie in diesem Beispiel eine Stat-Dateiebeneneinstellung von 4.  Dadurch wird sichergestellt, dass Inhalte geleert werden, die unter dem  us  -Ordner, der nicht dazu führt, dass auch die Sprachordner geleert werden.

STAT FILE TIMESTAMP HANDSHAKE

Wenn eine Inhaltsanforderung in derselben Routine erfolgt

CACHE HANDSHAKE - BEISPIEL 1

Im obigen Beispiel eine Anfrage für den Inhalt /content/index.html

Die Uhrzeit der Datei index.html ist 2019-11-01 @ 18:21PM.

Die Uhrzeit der nächsten STAT-Datei ist 2019-11-01 @ 12:22PM.

Wenn Sie wissen, was wir oben gelesen haben, können Sie sehen, dass die Indexdatei neuer ist als die STAT-Datei und die Datei vom Cache an den Endbenutzer gesendet wird, der sie angefordert hat

CACHE HANDSHAKE - BEISPIEL 2

Im obigen Beispiel eine Anfrage für den Inhalt /content/dam/logo.jpg

Die Zeit der Datei logo.jpg ist 2019-10-31 @ 1:13PM.

Die Uhrzeit der nächsten STAT-Datei ist 2019-11-01 @ 12:22PM.

Wie Sie in diesem Beispiel sehen können, ist die Datei älter als die STAT-Datei und wird entfernt und eine neue Datei wird von AEM abgerufen, um sie im Cache zu ersetzen, bevor sie an den Endbenutzer gesendet wird, der sie angefordert hat.

Farm-Dateieinstellungen

Die Dokumentation enthält alle Konfigurationsoptionen: https://docs.adobe.com/content/help/de-DE/experience-manager-dispatcher/using/configuring/dispatcher-configuration.html#configuring-dispatcher_configuring-the-dispatcher-cache-cache

Wir möchten einige von ihnen hervorheben, die sich auf die Cache-Leerung beziehen

Dokumentenstamm

Dieser Konfigurationseintrag befindet sich im folgenden Abschnitt der Farm-Datei:

Sie geben das Verzeichnis an, in dem der Dispatcher als Cache-Verzeichnis gefüllt und verwaltet werden soll.

Hinweis:

Dieser Ordner sollte mit der Apache Document Root-Einstellung für die Domäne übereinstimmen, für die Ihr Webserver konfiguriert ist.

Verschachtelte Basisordner pro Farm, die Unterordner des Apache-Basisverzeichnisses enthalten, sind aus vielen Gründen eine schreckliche Idee.

Ebene der statischen Dateien

Dieser Konfigurationseintrag befindet sich im folgenden Abschnitt der Farm-Datei:

Diese Einstellung misst, wie tief .stat-Dateien generiert werden müssen, wenn eine Leerungsanfrage eingeht.

/statfileslevel auf die folgende Zahl mit dem Dokumentenstamm von /var/www/html/ gesetzt, hätte beim Leeren von /content/dam/brand1/en/us/logo.jpg die folgenden Ergebnisse

Hinweis:

Denken Sie daran, dass der Zeitstempel-Handshake nach der nächstgelegenen STAT-Datei sucht.

Wenn die STAT-Dateiebene 0 und eine STAT-Datei nur unter /var/www/html/.stat vorhanden sind, bedeutet dies, dass Inhalt, der unter /var/www/html/content/dam/brand1/en/us/ lebt, nach der nächsten STAT-Datei sucht und fünf Ordner durchsucht, um die einzige STAT-Datei zu finden, die auf Ebene 0 existiert, und Datumsvergleiche.  Das bedeutet, dass eine Leerung auf dieser hohen Ebene im Wesentlichen alle zwischengespeicherten Elemente ungültig macht.

Invalidierung zulässig

Dieser Konfigurationseintrag befindet sich im folgenden Abschnitt der Farm-Datei:

Innerhalb dieser Konfiguration legen Sie eine Liste von IP-Adressen fest, die Leerungsanfragen senden dürfen.  Wenn eine Leerungsanfrage in den Dispatcher kommt, muss sie von einer vertrauenswürdigen IP-Adresse stammen.  Wenn Sie diese Konfiguration falsch konfiguriert haben oder eine Leerungsanfrage von einer nicht vertrauenswürdigen IP-Adresse senden, wird der folgende Fehler in der Protokolldatei angezeigt:

Invalidierungsregeln

Dieser Konfigurationseintrag befindet sich im folgenden Abschnitt der Farm-Datei:

Diese Regeln geben normalerweise an, welche Dateien bei einer Leerungsanfrage invalidiert werden dürfen.

Um zu verhindern, dass wichtige Dateien bei einer Seitenaktivierung invalidiert werden, können Sie Regeln anwenden, die angeben, welche Dateien invalidiert werden dürfen und welche manuell invalidiert werden müssen.  Im Folgenden finden Sie einen Beispielsatz an Konfigurationen, die nur die Invalidierung von HTML-Dateien ermöglichen:

Auflösung resolution

Tests/Fehlerbehebung

Wenn Sie eine Seite aktivieren und grünes Licht dafür erhalten, dass die Seitenaktivierung erfolgreich war, sollten Sie erwarten, dass der aktivierte Inhalt auch aus dem Cache geleert wird.

Sie aktualisieren Ihre Seite und sehen die alten Dinge, und es gibt grünes Licht.

Gehen wir ein paar manuelle Schritte durch den Leerungsprozess durch, um uns einen Einblick zu verschaffen, was falsch sein könnte.  Führen Sie in der Publisher-Shell die folgende Leerungsanforderung mit cURL aus:

Beispieltest für eine Leerungsanfrage

Nachdem Sie den Anforderungsbefehl an den Dispatcher ausgelöst haben, möchten Sie sehen, was in den Protokollen geschehen ist und was mit den STAT-Dateien passiert.  Verfolgen Sie die Protokolldatei und Sie sollten die folgenden Einträge sehen, um den Treffer der Leerungsanfrage beim Dispatcher-Modul zu bestätigen.

Nachdem wir nun sehen, dass das Modul die Leerungsanfrage erfasst und bestätigt hat, müssen wir sehen, wie es die STAT-Dateien beeinflusst hat.  Führen Sie den folgenden Befehl aus und beobachten Sie die Aktualisierung der Zeitstempel, wenn Sie eine weitere Flush-Benachrichtigung durchführen:

| $ watch -n 3 "find /mnt/var/www/html/ -type f -name " .stat " | xargs ls -la $1" |
| — |

Wie Sie aus dem Befehl sehen können, geben die Zeitstempel der aktuellen STAT-Dateien aus

Wenn wir die Flush-Benachrichtigung jetzt erneut ausführen, sehen Sie sich die Zeitstempel-Aktualisierung an

Vergleichen wir unsere Zeitstempel für Inhalte mit unseren Zeitstempeln für STAT-Dateien.

Wenn Sie sich einen der Zeitstempel ansehen, werden Sie feststellen, dass der Inhalt eine neuere Zeit hat als die STAT-Datei, die das Modul anweist, die Datei aus dem Cache bereitzustellen, da sie neuer als die STAT-Datei ist.

Im Klartext: Die Zeitstempel dieser Datei wurden aktualisiert, sodass sie nicht mehr „geleert“ oder ersetzt werden können.