Überwachung und Wartung der AEM-Instanz

Nach der Bereitstellung der AEM-Instanzen sind bestimmte Aufgaben erforderlich, um Betrieb, Leistung und Integrität zu überwachen und aufrechtzuerhalten.

Um potenzielle Probleme erkennen zu können, müssen Sie unbedingt wissen, wie Ihre Systeme unter normalen Bedingungen aussehen und sich verhalten. Dazu sollten Sie das System überwachen und über einen Zeitraum hinweg Daten erfassen.

Überprüfen Sie Folgendes	Zu beachten	Kommentar/Aktionen
Backup-Plan.		Gehen Sie wie folgt vor, um ein Backup für Ihre Instanz zu erstellen.
Plan für die Notfallwiederherstellung	Richtlinien Ihres Unternehmens für die Notfallwiederherstellung.
Ein System zur Fehlersuche steht Ihnen für das Problem-Reporting zur Verfügung.	Zum Beispiel Bugzilla, Jira oder eines von vielen anderen.
Dateisysteme werden überwacht.	Das CRX-Repository wird „eingeforen“, wenn nicht genügend freier Speicherplatz vorhanden ist. Es wird fortgesetzt, sobald Speicherplatz frei wird.	„*ERROR* LowDiskSpaceBlocker“-Meldungen werden in der Protokolldatei angezeigt, wenn der Speicherplatz zur Neige geht.
Protokolldateien werden überwacht.
Die Systemüberwachung wird (ständig) im Hintergrund ausgeführt.	Einschließlich CPU-, Arbeitsspeicher-, Festplatten- und Netzwerkauslastung. Verwendet wird z. B. iostat / vmstat / perfmon.	Protokollierte Daten werden angezeigt und können zum Nachverfolgen von Leistungsproblemen verwendet werden. Rohdaten sind ebenfalls verfügbar.
Die AEM-Leistung wird überwacht.	Einschließlich Anfragezähler zur Überwachung des Traffic-Niveaus.	Bei großem oder anhaltendem Leistungsverlust sollte eine detaillierte Analyse erfolgen.
Sie überwachen Ihre Replikationsagenten.
Regelmäßige Bereinigung von Workflow-Instanzen.	Repository-Größe und Workflow-Leistung.	Siehe Regelmäßige Bereinigung von Workflow-Instanzen.

Backups

Es hat sich bewährt, Backups für folgende Komponenten zu erstellen:

• Ihre Software Installation: vor/nach wichtigen Konfigurationsänderungen
• Der Inhalt im Repository - regelmäßig

In Ihrem Unternehmen gibt es wahrscheinlich eine Sicherungsrichtlinie, die Sie einhalten müssen. Zusätzlich sollten Sie sich überlegen, welche Komponenten Sie wann sichern, z. B. anhand folgender Kriterien:

• Wie wichtig das System und die Daten sind.
• Wie oft Änderungen an der Software oder an den Daten vorgenommen werden.
• Datenmenge und Kapazität können u. U. ein Problem darstellen, ebenso die für das Erstellen von Sicherungskopien benötigte Zeit.
• Ob die Sicherung durchgeführt werden kann, während Benutzer online sind, und welche Auswirkungen auf die Leistung zu erwarten sind.
• Die geografische Verteilung der Nutzer. Wann ist z. B. die beste Zeit für die Sicherung (um Auswirkungen so gering wie möglich zu halten)?
• Die Richtlinie Ihres Unternehmens für die Notfallwiederherstellung. Es gibt Richtlinien, anhand derer gesicherte Daten gespeichert werden müssen (z. B. an externen Standorten, auf bestimmten Medien und dergleichen).

Oft werden in regelmäßigen Abständen (z. B. täglich, wöchentlich oder monatlich) vollständige Backups und zwischendurch (z. B. stündlich, täglich oder wöchentlich) inkrementelle Backups erstellt.

Erstellen Sie ein Backup Ihrer installierten Software

Nach der Installation oder nach größeren Konfigurationsänderungen sollten Sie ein Backup der installierten Software erstellen.

Dazu müssen Sie erst ein Backup des gesamten Repositorys erstellen und dann folgende Schritte ausführen:

1. AEM anhalten.
2. Erstellen Sie eine vollständige Sicherungskopie von <cq-installation-dir> vom Dateisystem aus.

Erstellen Sie ein Backup Ihres Repositorys

Im Abschnitt Sicherung und Wiederherstellung der CRX-Dokumentation sind alle Aspekte der Sicherung des CRX-Repositorys abgedeckt.

Details zum Erstellen eines Hot-Backups im Online-Betrieb finden Sie unter Erstellen eines Online-Backups.

Versionsbereinigung

Das Tool Versionen bereinigen dient zum Bereinigen der Versionen eines Knotens oder einer Hierarchie von Knoten in Ihrem Repository. Der Hauptzweck ist die Verkleinerung des Repositorys durch Löschen alter Knotenversionen.

In diesem Abschnitt werden die Wartungsaufgaben im Zusammenhang mit der Versionsfunktion von AEM behandelt. Mit dem Tool Versionsbereinigung können Sie Versionen eines Knotens oder eine Knotenhierarchie Ihres Repository bereinigen. Der Hauptzweck ist die Verkleinerung des Repositorys durch Löschen alter Knotenversionen.

Überblick

Das Tool Versionsbereinigung ist in der Tools-Konsole unter „Versionsverwaltung“ oder direkt unter folgender URL verfügbar:

https://<server>:<port>/etc/versioning/purge.html

Startpfad Ein absoluter Pfad, auf dem die Bereinigung ausgeführt werden muss. Sie können den Startpfad auswählen, indem Sie auf den Navigatorbaum im Repository klicken.

Rekursiv Wenn Sie Daten bereinigen, können Sie den Vorgang an einem Knoten oder in der ganzen Hierarchie ausführen. Aktivieren Sie hierfür die Option „Rekursiv“. Im letzteren Fall definiert der angegebene Pfad den Stammknoten der Hierarchie.

Maximale Anzahl an beizubehaltenden Versionen Die maximale Anzahl von Versionen, die für einen Knoten beibehalten werden sollen. Wenn die Anzahl diesen Wert überschreitet, werden die ältesten Versionen gelöscht.

Maximales Versionsalter Das maximale Alter der Version eines Knotens. Wenn das Alter einer Version diesen Wert überschreitet, wird sie gelöscht.

Probelauf Da das Entfernen von Versionen endgültig ist und nur durch Wiederherstellen eines Backups rückgängig gemacht werden kann, ist beim Tool für die Versionsbereinigung ein Probelauf-Modus verfügbar, der Ihnen eine Vorschau auf die bereinigte Version erlaubt. Klicken Sie auf „Probelauf“, um einen Probelauf des Bereinigungsvorgangs zu starten.

Bereinigen Starten Sie das Bereinigen der Versionen auf dem Knoten, der durch den Startpfad definiert ist.

Bereinigen von Versionen einer Website

Um Versionen einer Website zu löschen, gehen Sie folgendermaßen vor:

1. Navigieren Sie zur Tools-Konsole, wählen Sie Versionsverwaltung aus und doppelklicken Sie auf Versionen bereinigen.

2. Legen Sie den Startpfad für den zu löschenden Inhalt fest (z. B. /content/geometrixx-outdoors).

   • Falls Sie nur den durch den Pfad definierten Knoten löschen möchten, deaktivieren Sie die Option „Rekursiv“.
   • Falls Sie den durch den Pfad definierten Knoten und alle untergeordneten Knoten bereinigen möchten, aktivieren Sie die Option „Rekursiv“.

3. Legen Sie die maximale Anzahl von Versionen (für jeden Knoten) fest, die Sie beibehalten möchten. Lassen Sie das Feld frei, falls diese Einstellung nicht verwendet werden soll.

4. Legen Sie das maximale Versionsalter in Tagen (für jeden Knoten) fest, den Sie beibehalten möchten. Lassen Sie das Feld frei, falls diese Einstellung nicht verwendet werden soll.

5. Klicken Sie auf Probelauf, um eine Vorschau des Bereinigungsvorgangs anzuzeigen.

6. Klicken Sie auf Löschen, um den Vorgang zu starten.

Analysieren der Konsole

Beim den Vorgängen Probelauf und Löschen werden alle Knoten aufgelistet, die verarbeitet werden. Während des Vorgangs kann ein Knoten einen der folgenden Statuswerte haben:

• ignore (not versionnable): Der Knoten unterstützt keine Versionierung und wird beim Bereinigungsvorgang ignoriert.
• ignore (no version): Für den Knoten sind keine Versionen vorhanden und er wird beim Bereinigungsvorgang ignoriert.
• retained: Der Knoten wurde nicht gelöscht.
• purged: Der Knoten wurde gelöscht.

Darüber hinaus stellt die Konsole nützliche Informationen zu den Versionen bereit:

• V 1.0: Die Versionsnummer.
• V 1.0.1*: Der Stern zeigt an, dass die Version die aktuelle ist.
• Thu Mar 15 2012 08:37:32 GMT+0100: Das Datum der Version.

Im Folgenden ein Beispiel:

• Die Versionen unter Shirts werden gelöscht, da sie älter als 2 Tage sind.
• Die Versionen unter Tonga Fashions! Versionen werden gelöscht, da die Anzahl der Versionen größer als 5 ist.

Arbeiten mit Auditdatensätzen und Protokolldateien

Auditdatensätze und Protokolldateien für Adobe Experience Manager (AEM) finden sich an diversen Speicherorten. Im Folgenden erhalten Sie einen Überblick, welche Dateien wo zu finden sind.

Arbeiten mit Protokollen

AEM WCM-System zeichnet detaillierte Protokolle auf. Wenn Sie Quickstart entpackt und gestartet haben, finden Sie Protokolle unter folgenden Pfaden:

• <cq-installation-dir>/crx-quickstart/logs/
• <cq-installation-dir>/crx-quickstart/repository/

Protokolldateirotation

Protokolldateirotation bezeichnet einen Vorgang, bei dem das Dateiwachstum durch das regelmäßige Erstellen einer neuen Datei beschränkt wird. In AEM wird die Protokolldatei error.log täglich nach folgenden Regeln rotiert:

• Die Datei error.log wird nach dem Muster {Original_Dateiname} .yyyy-MM-dd umbenannt. Beispielsweise wird die aktuelle Protokolldatei am 11. Juli 2010 umbenannt in error.log-2010-07-10 und anschließend wird ein neues error.og erstellt.
• Vorherige Protokolldateien werden nicht gelöscht. Sie sind dafür verantwortlich, alte Protokolldateien regelmäßig zu löschen, um den Speicherbedarf zu beschränken.

Suchen nach Protokolldateien

Diverse Protokolldateien werden auf dem Dateiserver gespeichert, auf dem Sie AEM installiert haben:

• <cq-installation-dir>/crx-quickstart/logs

  • access.log

    Hier werden alle Zugriffsanfragen an das AEM WCM-System und das Repository registriert.

  • audit.log

    Hier werden Moderationsaktionen registriert.

  • error.log

    Hier werden Fehlermeldungen (mit unterschiedlichem Schweregrad) registriert.

  • ImageServer-<PortId>-yyyy>-<mm>-<dd>.log

    Dieses Protokoll wird nur verwendet, wenn Dynamic Media aktiviert ist. Es stellt die Statistiken und analytische Informationen bereit, die für die Analyse des Verhaltens des internen ImageServer-Prozesses verwendet werden.

  • request.log

    Hier werden alle Zugriffsanfragen zusammen mit der Antwort registriert.

  • s7access-<yyyy>-<mm>-<dd>.log

    Dieses Protokoll wird nur verwendet, wenn Dynamic Media aktiviert ist. Das s7access-Protokoll zeichnet alle Anfragen auf, die über an Dynamic Media gesendet werden /is/image und /is/content.

  • stderr.log

    Enthält Fehlermeldungen (ebenfalls mit unterschiedlichem Schweregrad), die beim Starten generiert werden. Standardmäßig wird für die Protokollebene Folgendes festgelegt Warning ( WARN)

  • stdout.log

    Enthält Protokollmeldungen, die auf Ereignisse beim Starten verweisen.

  • upgrade.log

    Bietet ein Protokoll aller Aktualisierungsvorgänge, die von der com.day.compat.codeupgrade und com.adobe.cq.upgradesexecutor Packages.

• <cq-installation-dir>/crx-quickstart/repository

  • revision.log

    Zeigt Daten des Revisionsjournals an.

Aktivieren der DEBUG-Protokollebene

Die standardmäßige Protokollebene Apache Sling Logging Configuration ist Information, sodass Debugmeldungen nicht protokolliert werden.

Um die Debugging-Protokollebene für eine Protokollierung zu aktivieren, müssen Sie für die Eigenschaften org.apache.sling.commons.log.level im Repository den Wert „debug“ festlegen. Beispielsweise auf /libs/sling/config/org.apache.sling.commons.log.LogManager, um die globale Apache Sling-Protokollierung zu konfigurieren.

Eine Zeile in der Debugging-Datei beginnt üblicherweise mit DEBUG, gefolgt von der Protokollebene, der Installationsaktion und der Protokollmeldung. Beispiel:

DEBUG 3 WebApp Panel: WebApp successfully deployed

Die Protokollebenen lauten wie folgt:

0	Schwerwiegender Fehler	Die Aktion ist fehlgeschlagen und das Installationsprogramm kann nicht fortgesetzt werden.
1	Fehler	Die Aktion ist fehlgeschlagen. Die Installation wird fortgesetzt, ein Teil des AEM WCM-Systems wird jedoch nicht richtig installiert und funktioniert nicht.
2	Warnung	Die Aktion war erfolgreich, stieß aber auf Probleme. Das AEM WCM-System funktioniert möglicherweise nicht ordnungsgemäß.
3	Informationen	Die Aktion war erfolgreich.

Erstellen einer benutzerdefinierten Protokolldatei

Unter bestimmten Umständen müssen Sie möglicherweise eine benutzerdefinierte Protokolldatei mit einer anderen Protokollebene erstellen. Gehen Sie dazu im Repository wie folgt vor:

1. Erstellen Sie, falls nicht bereits vorhanden, einen neuen Konfigurationsordner (sling:Folder) für das Projekt /apps/<project-name>/config.

2. Erstellen Sie unter /apps/<project-name>/config einen Knoten für die neue Apache Sling Logging Logger-Konfiguration:

   • Name:

   org.apache.sling.commons.log.LogManager.factory.config-<identifier> (da dies ein Logger ist)

   wobei <identifier> durch einen freien Text ersetzt wird, den Sie eingeben (müssen), um die Instanz zu identifizieren (diese Information darf nicht weggelassen werden). Beispiel: org.apache.sling.commons.log.LogManager.factory.config-MINE

   • Typ: sling:OsgiConfig
   HINWEIS

   Es gibt zwar keine spezifischen technischen Anforderungen, es ist jedoch ratsam, für <identifier> einen eindeutigen Parameter zu verwenden.

3. Legen Sie die folgenden Eigenschaften des Knotens fest:

   • Name: org.apache.sling.commons.log.file

     Typ: String

     Wert: Angabe der Protokolldatei; Beispiel: logs/myLogFile.log

   • Name: org.apache.sling.commons.log.names

     Typ: String[] (String + Multi)

     Wert: Angabe der OSGi-Services, für die der Logger Meldungen protokollieren soll, beispielsweise alle folgenden:

     • org.apache.sling
     • org.apache.felix
     • com.day

   • Name: org.apache.sling.commons.log.level

     Typ: String

     Wert: Angabe der erforderliche Protokollebene (debug, info, warn oder error); Beispiel debug

   • Konfigurieren Sie ggf. weitere Parameter:

     • Name: org.apache.sling.commons.log.pattern

       Typ: String

       Wert: Angabe des Musters der Protokollmeldung nach Bedarf; Beispiel:

       {0,date,dd.MM.yyyy HH:mm:ss.SSS} *{4}* [{2}] {3} {5}

   HINWEIS

   org.apache.sling.commons.log.pattern unterstützt bis zu sechs Argumente.

   {0} Der Zeitstempel vom Typ java.util.Date

   {1} Die Protokollmarkierung

   {2} Der Name des aktuellen Threads

   {3} Der Name des Loggers

   {4} Die Protokollierungsebene

   {5} Die Protokollmeldung

   Falls der Protokollaufruf den Parameter Throwable enthält, wird der StackTrace an die Meldung angefügt.

   VORSICHT

   „org.apache.sling.commons.log.names“ muss einen Wert enthalten.

   HINWEIS

   Die Protokollierungspfade sind vom Speicherort-crx-quickstartabhängig.

   Eine Protokolldatei wie:

   logs/thelog.log

   wird daher geschrieben in:

   <cq-installation-dir>/crx-quickstart/logs/thelog.log.

   Und eine Protokolldatei wie:

   ../logs/thelog.log

   wird in folgendes Verzeichnis geschrieben:

   <cq-installation-dir>/logs/
   (d. h. neben <cq-installation-dir>/crx-quickstart/)

4. Dieser Schritt muss nur ausgeführt werden, wenn ein neuer Writer erforderlich ist (d. h. mit einer Konfiguration, die vom standardmäßigen Writer abweicht).

   VORSICHT

   Eine neue Logging-Writer-Konfiguration ist nur erforderlich, wenn die vorhandene Standardkonfiguration nicht geeignet ist.
   Wenn kein expliziter Writer konfiguriert ist, erstellt das System automatisch einen impliziten Writer auf Basis der Standardkonfiguration.

   Erstellen Sie unter /apps/<project-name>/config einen Knoten für die neue Apache Sling Logging-Primär-Konfiguration:

   • Name: org.apache.sling.commons.log.LogManager.factory.writer-<identifier> (da dies ein Primär ist)

     Wie beim Logger wird <identifier> durch einen freien Text ersetzt, den Sie eingeben (müssen), um die Instanz zu identifizieren (diese Information darf nicht weggelassen werden). Beispiel: org.apache.sling.commons.log.LogManager.factory.writer-MINE

   • Typ: sling:OsgiConfig

   HINWEIS

   Es gibt zwar keine spezifischen technischen Anforderungen, es ist jedoch ratsam, für <identifier> einen eindeutigen Parameter zu verwenden.

   Legen Sie die folgenden Eigenschaften des Knotens fest:

   • Name: org.apache.sling.commons.log.file

     Typ: String

     Wert: Angabe der Protokolldatei in einer Weise, dass sie mit der im Logger angegebenen Datei übereinstimmt.

     Für dieses Beispiel: ../logs/myLogFile.log.

   • Konfigurieren Sie ggf. weitere Parameter:

     • Name: org.apache.sling.commons.log.file.number

       Typ: Long

       Wert: Angabe der Anzahl der Protokolldateien, die Sie beibehalten möchten; wie z. B. 5

     • Name: org.apache.sling.commons.log.file.size

       Typ: String

       Wert: Geben Sie diesen wie erforderlich an, um die Dateirotation nach Größe/Datum zu steuern; beispielsweise '.'yyyy-MM-dd

   HINWEIS

   org.apache.sling.commons.log.file.size steuert die Rotation der Protokolldatei durch eine der folgenden Einstellungen:

   • eine maximalen Dateigröße
   • einen Zeit-/Terminplan

   um anzugeben, wann eine neue Datei erstellt wird (und die vorhandene Datei gemäß dem Namensmuster umbenannt wird).

   • Eine Größenbeschränkung kann mit einer Zahl angegeben werden. Falls kein Größenindikator angegeben ist, gilt die Anzahl der Bytes oder Sie können einen der folgenden Indikatoren hinzufügen: KB, MB oder GB (Groß-/Kleinschreibung wird ignoriert).
   • Sie können einen Zeit-/Terminplan nach dem java.util.SimpleDateFormat-Muster angeben. Dieser gibt den Zeitraum an, in dem die Datei rotiert wird, sowie das Suffix, das an die rotierte Datei angehängt wurde (zur einfachen Identifizierung).

   Der Standardwert lautet „.“jjjj-MM-tt (für die tägliche Protokollrotation).

   So wird beispielsweise um Mitternacht am 20. Januar 2010 (oder sobald die erste Protokollmeldung nach diesem Zeitpunkt ausgegeben wird), …/logs/error.log in …/logs/error.log.2010-01-20 umbenannt. Die Protokollierung für den 21. Januar erfolgt in (ein neues und leeres) …/logs/error.log und geht bei der nächsten Änderung zum nächsten Datum über.

   '.'yyyy-MM	Rotation zu Beginn jedes Monats
   '.'yyyy-ww	Rotation am ersten Tag jeder Woche (hängt vom Gebietsschema ab).
   '.'yyyy-MM-dd	Rotation täglich um Mitternacht.
   '.'yyyy-MM-dd-a	Rotation täglich um Mitternacht und am Mittag.
   '.'yyyy-MM-dd-HH	Rotation zu jeder vollen Stunde.
   '.'yyyy-MM-dd-HH-mm	Rotation zu Beginn jeder Minute.

   Hinweis: Bei der Angabe einer Uhrzeit/eines Datums ist Folgendes zu beachten:

   1. Sie sollten wörtlichen Text innerhalb eines Paares einfacher Anführungszeichen (' ') „ausklammern“;

      Dadurch wird verhindert, dass bestimmte Zeichen als Musterbuchstaben interpretiert werden.

   2. Verwenden Sie nur Zeichen, die für einen gültigen Dateinamen im Optionsfeld zulässig sind.

5. Lesen Sie die neue Protokolldatei mit dem von Ihnen ausgewählten Tool.

   Die Protokolldatei, die für dieses Beispiel erstellte wurde, lautet wie folgt ../crx-quickstart/logs/myLogFile.log.

Die Felix-Konsole enthält auch Informationen zum Sling Log-Support unter ../system/console/slinglog; beispielsweise http://localhost:4502/system/console/slinglog.

Suchen nach Auditdatensätzen

Auditdatensätze werden als Nachweis darüber aufbewahrt, wer wann welche Aktion vorgenommen hat. Verschiedene Auditdatensätze werden für das AEM WCM-System und OSGi-Ereignisse generiert.

Bei der Seitenbearbeitung angezeigte AEM WCM-Auditdatensätze

1. Öffnen Sie eine Seite.

2. Wählen Sie im Seitenmenü die Registerkarte mit dem Sperrsymbol aus und doppelklicken Sie auf Auditprotokoll…

3. Ein neues Fenster wird geöffnet, in dem die Liste der Auditdatensätze für die aktuelle Seite angezeigt werden.

   

4. Klicken Sie auf OK, wenn Sie das Fenster schließen möchten.

AEM WCM-Auditdatensätze im Repository

Auditdatensätze werden im Ordner /var/audit je nach Ressource gespeichert. Sie können ein Drilldown durchführen, bis einzelne Datensätze und die darin enthaltenen Informationen angezeigt werden.

Diese Einträge enthalten die gleichen Informationen wie sie beim Bearbeiten einer Seite angezeigt werden.

OSGi-Auditdatensätze aus der Web-Konsole

OSGi-Ereignisse generieren ebenfalls Auditdatensätze, die Sie in der AEM-Web-Konsole auf der Registerkarte Konfigurationsstatus unter Protokolldateien anzeigen können:

Überwachen der Replikationsagenten

Sie können Replikations-Warteschlangen darauf überwachen, ob eine Warteschlange ausgefallen oder gesperrt ist. Dies kann wiederum auf ein Problem mit einer Veröffentlichungsinstanz oder einem externen System hinweisen:

• Sind alle erforderlichen Warteschlangen aktiviert?

• Sind alle deaktivierten Warteschlangen noch erforderlich?

• Alle enabled Warteschlangen sollten den Status idle oder active aufweisen, was einem normalem Betrieb entspricht. Keine der Warteschlangen sollte den Status blocked aufweisen, da dies oft auf Probleme auf Empfängerseite hinweist.

• Wenn die Warteschlange im Laufe der Zeit größer wird, kann dies auf eine Blockierung hindeuten.

Gehen Sie wie folgt vor, um Replikationsagenten zu überwachen:

1. Wechseln Sie in AEM zur Registerkarte Tools.

2. Klicken Sie auf Replikation.

3. Doppelklicken Sie auf den Link zu den Agenten für die jeweilige Umgebung (entweder der linke oder der rechte Fensterbereich); z. B.Agenten für Autor.

   Das daraufhin angezeigte Fenster gibt einen Überblick über alle Replikationsagenten für die Autorenumgebung, einschließlich ihrer Ziele und Status.

4. Klicken Sie auf den jeweiligen Agenten (der als Link dargestellt ist), um detaillierte Informationen zu diesem Agenten anzuzeigen:

   

   Folgende Informationen/Optionen sind verfügbar:

   • Ob der Agent aktiviert ist.
   • Das Ziel einer beliebigen Replikation.
   • Ob die Replikations-Warteschlange derzeit aktiv (aktiviert) ist.
   • Ob die Warteschlange Elemente enthält.
   • Aktualisieren oder Löschen zum Aktualisieren der angezeigten Elemente in der Warteschlange. Mit diesen Optionen können Sie Elemente anzeigen, die in die Warteschlange gestellt werden oder diese verlassen.
   • Protokoll anzeigen für den Zugriff auf das Protokoll beliebiger Aktionen des Replikationsagenten.
   • Verbindung testen zum Testen der Verbindung mit der Zielinstanz.
   • Erneuten Versuch erzwingen, um einen erneuten Versuch auf beliebigen Elementen der Warteschlange zu erzwingen, falls erforderlich.
   VORSICHT

   Verwenden Sie den Link „Verbindung testen“ nicht für den Postausgang der Rückwärtsreplikation auf der Veröffentlichungsinstanz.

   Falls Sie eine Replikation für eine Warteschlange in einem Postausgang testen, werden alle Elemente, die älter als die Testreplikation sind, bei jeder Rückwärtsreplikation erneut verarbeitet.

   Wenn solche Elemente bereits in einer Warteschlange vorhanden sind, können Sie mit der folgenden XPath JCR-Abfrage danach suchen und diese entfernen.

   /jcr:root/var/replication/outbox//*[@cq:repActionType='TEST']

Auch hier können Sie eine Lösung entwickeln, um alle Replikationsagenten (unter /etc/replication/author oder /etc/replication/publish) zu erkennen und den Status des jeweiligen Agenten (enabled, disabled) sowie den der zugrunde liegenden Warteschlange (active, idle, blocked) zu überprüfen.

Leistungsüberwachung

Die Leistungsoptimierung ist ein interaktiver Vorgang, der bei der Entwicklung Priorität hat. Im Anschluss an die Bereitstellung wird die Leistung nach bestimmten Intervallen oder Ereignissen überprüft.

Die für das Erfassen von Informationen eingesetzten Methoden können auch zur kontinuierlichen Überwachung verwendet werden.

Nachfolgend finden Sie eine Liste mit häufigen Leistungsproblemen und Vorschlägen, wie Sie diese erkennen und beheben.

Bereich	Symptom(e)	So steigern Sie Kapazitäten:	So reduzieren Sie Mengen:
Client	Hohe Auslastung der CPU durch den Client.	Installieren Sie eine Client-CPU mit höherer Leistung.	Vereinfachen Sie das (HTML-)Layout.
	Geringe CPU-Auslastung des Servers.	Aktualisieren Sie auf einen schnelleren Browser.	Optimieren Sie den Client-seitigen Cache.
	Einige Clients sind schnell, andere langsamer.
Server
Netzwerk	Geringe CPU-Auslastung sowohl auf Servern als auch auf Clients.	Beseitigen Sie eventuelle Netzwerkengpässe.	Verbessern/optimieren Sie die Konfiguration des Client-Cache.
	Die lokale Suche auf dem Server ist (vergleichsweise) schnell.	Vergrößern Sie die Netzwerkbandbreite.	Verringern Sie das „Gewicht“ Ihrer Website (z. B. weniger Bilder, optimiertes HTML).
Webserver	Die CPU-Auslastung auf dem Webserver ist hoch.	Erstellen Sie Webserver-Cluster.	Reduzieren Sie die Treffer pro Seite (Aufruf).
		Verwenden Sie einen Hardware Load Balancer.
Programm	Die CPU-Auslastung des Servers ist hoch.	Erstellen Sie Cluster Ihrer AEM-Instanzen.	Suchen Sie nach und beseitigen Sie CPU- und Arbeitsspeicherverschwendung (durch Überprüfung von Code, zeitliche Planung von Ausgaben usw.).
	Hoher Speicherverbrauch.		Verbessern Sie das Zwischenspeichern auf allen Ebenen.
	Kurze Antwortzeiten.		Optimieren Sie Vorlagen und Komponenten (z. B. Struktur, Logik).
Repository
Cache

Leistungsprobleme können eine Reihe von Ursachen haben, die nichts mit Ihrer Website zu tun haben, z. B. eine vorübergehend langsamere Verbindungsgeschwindigkeit, CPU-Auslastung und vieles mehr.

Sie können sich auf alle Besucher oder nur bestimmte Benutzergruppen auswirken.

All diese Informationen müssen erfasst, sortiert und analysiert werden, bevor Sie die allgemeine Leistung optimieren oder gezielt Probleme lösen können.

• Bevor es zu einem Leistungsproblem kommt:

  • Sammeln Sie so viele Informationen wie möglich, um sich ein gutes Bild des Systems unter normalen Bedingungen zu machen.

• Wenn es zu einem Leistungsproblem kommt:

  • Versuchen Sie, das Problem mit einem (oder vorzugsweise mehr als einem) Standard-Webbrowser, auf einem anderen leistungsstarken Client oder, falls möglich, direkt auf dem Server zu replizieren.

  • Überprüfen Sie, ob (am System) in einem bestimmten Zeitraum Änderungen aufgetreten sind und ob diese Änderungen die Leistung beeinträchtigen können.

  • Stellen Sie Fragen wie:

    • Tritt das Problem nur zu bestimmten Zeitpunkten auf?
    • Tritt das Problem nur auf bestimmten Seiten auf?
    • Sind andere Anforderungen davon betroffen?

  • Sammeln Sie so viele Informationen wie möglich, um diese mit den Information zu vergleichen, die Sie zum System unter normalen Bedingungen haben:

Tools für die Leistungsüberwachung und -analyse

Im Folgenden finden Sie einen kurzen Überblick über Tools, mit denen Sie die Leistung überwachen und analysieren können.

Einige von diesen sind von Ihrem Betriebssystem abhängig.

Tool	Zur Analyse genutzt:	Verwendung/Weitere Informationen:
request.log	Antwortzeiten und parallele Verarbeitung.	Interpretieren von request.log.
truss/strace	Seitenladenvorgänge	Unix-/Linux-Befehle zur Verfolgung von Systemaufrufen und Signalen. Erhöhen Sie die Protokollebene auf INFO. Analysieren Sie die Seitenladefrequenz pro Anforderung, welche Seiten geladen wurden usw.
Thread-Dumps	Beobachten Sie die JVM-Threads. Identifizieren Sie Konflikte, Sperren und lange Ausführungszeiten.	Abhängig von Betriebssystem: – Unix/Linux: kill -QUIT <pid> – Windows (Konsolenmodus): Strg-Umbruch Analyse-Tools sind ebenso verfügbar, wie zum Beispiel TDA.
Heap-Dumps	Probleme mit dem Speicher, die zu Leistungsverlusten führen.	Fügen Sie die Option -XX:+HeapDumpOnOutOfMemoryError beim Java-Auruf für AEM hinzu. Siehe Anleitung zur Fehlersuche für Java SE 6 with HotSpot VM.
Systemaufrufe	Erkennen von Zeitproblemen.	Ruft System.currentTimeMillis() oder com.day.util auf. Die Zeitmessung wird verwendet, um Zeitstempel aus Ihrem Code oder über HTML-Kommentare zu generieren. Hinweis: Diese sollten implementiert werden, damit sie bei Bedarf aktiviert/deaktiviert werden können. Wenn ein System reibungslos läuft, können Sie den Mehraufwand für das Erfassen von Statistiken vermeiden.
Apache Bench	Identifizieren Sie Speicherlecks, analysieren Sie selektiv Reaktionszeiten.	Grundlegende Verwendung: ab -k -n <requests> -c <concurrency> <url> Weitere Einzelheiten finden Sie unter Apache Bench und auf der ab man-Seite.
Rechercheanalyse		Führen Sie Suchabfragen offline aus, ermitteln Sie die Antwortzeit der Abfrage, testen und bestätigen Sie den Ergebnissatz.
JMeter	Last- und Funktionstest.	https://jakarta.apache.org/jmeter/
JProfiler	Detaillierte CPU- und Speicherprofilerstellung.	https://www.ej-technologies.com/
JConsole	Beobachten Sie JVM-Metriken und -Threads.	Verwendungszweck: jconsole Siehe jconsole und Leistungsüberwachung mit JConsole. Hinweis: Bei JDK 1.6 ist JConsole durch Plug-ins erweiterbar; z. B. Top oder TDA (Thread Dump Analyzer).
Java VisualVM	Beobachten Sie JVM-Metriken, Threads, Arbeitsspeicher und Profiling.	Verwendungszweck: jvisualvm oder visualvm Siehe jvisualvm, visualvm und Leistungsüberwachung mit (J)VisualVM. Hinweis: Bei JDK 1.6 ist VisualVM durch Plug-ins erweiterbar.
truss/strace, Isof	Detaillierter Kernelaufruf und Prozessanalyse (Unix).	Unix-/Linux-Befehle.
Zeitstatistiken	Siehe Zeitstatistiken für das Laden von Seiten.	Zum Anzeigen von Zeitstatistiken für das Laden von Seiten können Sie Strg-Umschalt-U verwenden, wobei in der URL ?debugClientLibs=true festgelegt ist.
CPU- und Speicher-Profiling-Tool	Wird für die Analyse langsamer Anfragen während der Entwicklung verwendet.	Zum Beispiel YourKit.
Informationserfassung	Der aktuelle Stand Ihrer Installation.	Wenn Sie möglichst viel über Ihre Installation wissen, kann Ihnen dies unter Umständen helfen, die Ursache für die Leistungsänderung herauszufinden und ob diese Änderungen sich begründen lassen. Diese Metriken müssen in regelmäßigen Abständen erfasst werden, sodass Sie signifikante Änderungen sofort sehen.

Interpretieren von request.log

In dieser Datei werden grundlegende Informationen zu allen Anforderungen an AEM registriert. Sie können daraus wertvolle Schlüsse ziehen.

request.log ist eine integrierte Möglichkeit herauszufinden, wie lange Anforderungen brauchen. Zu Entwicklungszwecken ist es hilfreich, den Befehl tail -f auf request.log anzuwenden und nach langen Systemreaktionen zu suchen. Für das Analysieren einer größeren request.log empfiehlt sich die Verwendung von rlog.jar, damit Sie nach Systemreaktionszeiten filtern und diese sortieren können.

Es wird empfohlen, „langsame“ Seiten aus request.log zu isolieren und einzeln für eine bessere Leistung zu optimieren. Dazu können Sie Leistungsmetriken pro Komponente oder ein Leistungprofil-Tool wie [yourkit](https://www.yourkit.com/) verwenden.

Überwachen der Traffic auf Ihrer Webseite

Im Anforderungsprotokoll werden alle Anfragen zusammen mit der jeweiligen Antwort registriert:

09:43:41 [66] -> GET /author/y.html HTTP/1.1
09:43:41 [66] <- 200 text/html 797ms

Durch Addieren aller GET-Einträge über einen bestimmten Zeitraum (z. B. über mehrere 24-Stunden-Zeiträume) erhalten Sie aussagekräftige Informationen zum durchschnittlichen Traffic auf Ihrer Website.

Überwachung der Antwortzeiten mit request.log

Ein guter Ausgangspunkt für Leistungsanalysen ist das Anforderungsprotokoll:

<cq-installation-dir>/crx-quickstart/logs/request.log

Das Protokoll sieht wie folgt aus (die Zeilen sind der Einfachheit halber gekürzt):

31/Mar/2009:11:32:57 +0200 [379] -> GET /path/x HTTP/1.1
31/Mar/2009:11:32:57 +0200 [379] <- 200 text/html 33ms
31/Mar/2009:11:33:17 +0200 [380] -> GET /path/y HTTP/1.1
31/Mar/2009:11:33:17 +0200 [380] <- 200 application/json 39ms

Dieses Protokoll enthält eine Zeile pro Anforderung oder Antwort mit:

• dem Datum, an dem jede Anforderung oder Antwort erfolgte;

• der Anzahl an Anforderungen, in eckigen Klammern; deren Zahl mit der Anfrage und der Antwort übereinstimmt;

• einem Pfeil, der angibt, ob es sich um eine Anfrage (Pfeil nach rechts) oder eine Antwort (Pfeil nach links) handelt.

• Bei Anforderungen enthält die Zeile:

  • die Methode (in der Regel GET, HEAD oder POST);
  • die angeforderte Seite;
  • das Protokoll.

• Bei Antworten enthält die Zeile:

  • den Statuscode (200 steht für „Erfolg“, 404 steht für „Seite nicht gefunden“);
  • den MIME-Typ;
  • die Antwortzeit.

Anhand von kleinen Skripts können Sie die erforderlichen Informationen aus der Protokolldatei extrahieren und die gewünschten Statistiken erstellen. Daraus können Sie ersehen, welche Seiten oder Seitentypen langsam reagieren und ob die Gesamtleistung zufriedenstellend ist.

Überwachung der Suchantwortzeiten mit request.log

Suchanforderungen werden ebenfalls in der Protokolldatei registriert:

31/Mar/2009:11:35:34 +0200 [338] -> GET /author/playground/en/tools/search.html?query=dilbert&size=5&dispenc=utf-8 HTTP/1.1
31/Mar/2009:11:35:34 +0200 [338] <- 200 text/html 1562ms

Wie oben bereits erwähnt, können Sie Skripts verwenden, um relevante Informationen zu extrahieren und Statistiken zu erstellen.

Wenn Sie die Antwortzeit bestimmt haben, müssen Sie möglicherweise analysieren, warum die Anforderung diese Zeit benötigt und wie sie diese verbessern können.

Überwachen der Anzahl und Auswirkung gleichzeitiger Benutzer

Sie können request.log verwenden, um die gleichzeitige Nutzung und die Systemreaktion darauf zu überwachen.

Sie sollten testen, wie viele gleichzeitige Benutzer das System unterstützt, bevor es zu Leistungseinbußen kommt. Auch hier können Skripts verwendet werden, um die Ergebnisse aus der Protokolldatei zu extrahieren:

• Überwachen Sie, wie viele Anforderungen in einem bestimmten Zeitraum erfolgen, z. B. in einer Minute.
• Testen Sie die Auswirkungen, wenn eine bestimmte Anzahl Benutzer die gleiche Anforderung zur (möglichst) gleichen Zeit senden; z. B. 30 Benutzer klicken gleichzeitig auf Speichern.

31/Mar/2009:11:45:29 +0200 [333] -> GET /author/libs/Personalize/content/statics.close.gif HTTP/1.1
31/Mar/2009:11:45:29 +0200 [334] -> GET /author/libs/Personalize/content/statics.detach.gif HTTP/1.1
31/Mar/2009:11:45:30 +0200 [335] -> GET /author/libs/CFC/content/imgs/logo.rZMNURccynWcTpCxyuBNiTCoiBMmw000.default.gif HTTP/1.1
31/Mar/2009:11:45:32 +0200 [335] <- 304 text/html 0ms
31/Mar/2009:11:45:33 +0200 [334] <- 200 image/gif 31ms
31/Mar/2009:11:45:38 +0200 [333] <- 200 image/gif 31ms
31/Mar/2009:11:45:42 +0200 [336] -> GET /author/libs/CFC/content/imgs/logo.rZMNURccynWcTZRXunQbbQtvuuCMbRRBuWXz0000.default.gif HTTP/1.1
31/Mar/2009:11:45:43 +0200 [337] -> GET /author/titlebar_bg.gif HTTP/1.1
31/Mar/2009:11:45:43 +0200 [336] <- 304 text/html 0ms
31/Mar/2009:11:45:44 +0200 [337] <- 304 text/html 0ms

Verwenden von rlog.jar bei der Suche nach Anforderungen mit langer Dauer

AEM umfasst verschiedene Hilfs-Tools unter:
<cq-installation-dir>/crx-quickstart/opt/helpers

Eines dieser Tools, rlog.jar, kann zum schnellen Sortieren von request.log verwendet werden, sodass Anforderungen nach Dauer (längste bis kürzeste Zeit) angezeigt werden.

Der folgende Befehl zeigt die möglichen Argumente:

$java -jar rlog.jar
Request Log Analyzer Version 21584 Copyright 2005 Day Management AG
Usage:
  java -jar rlog.jar [options] <filename>
Options:
  -h               Prints this usage.
  -n <maxResults>  Limits output to <maxResults> lines.
  -m <maxRequests> Limits input to <maxRequest> requests.
  -xdev            Exclude POST request to CRXDE.

Beispielsweise können Sie das Tool mit der request.log-Datei als Parameter ausführen und die ersten 10 Anforderungen mit der längsten Dauer anzeigen:

$ java -jar ../opt/helpers/rlog.jar -n 10 request.log
*Info * Parsed 464 requests.
*Info * Time for parsing: 22ms
*Info * Time for sorting: 2ms
*Info * Total Memory: 1mb
*Info * Free Memory: 1mb
*Info * Used Memory: 0mb
------------------------------------------------------
     18051ms 31/Mar/2009:11:15:34 +0200 200 GET /content/geometrixx/en/company.html text/ html
      2198ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/cq/widgets.js application/x-javascript
      1981ms 31/Mar/2009:11:15:11 +0200 200 GET /libs/wcm/content/welcome.html text/html
      1973ms 31/Mar/2009:11:15:52 +0200 200 GET /content/campaigns/geometrixx.teasers..html text/html
      1883ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/security/cq-security.js application/x-javascript
      1876ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/tagging/widgets.js application/x-javascript
      1869ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/tagging/widgets/themes/default.js application/x-javascript
      1729ms 30/Mar/2009:16:45:56 +0200 200 GET /libs/wcm/content/welcome.html text/html; charset=utf-8
      1510ms 31/Mar/2009:11:15:34 +0200 200 GET /bin/wcm/contentfinder/asset/view.json/ content/dam?_dc=1238490934657&query=&mimeType=image&_charset_=utf-8 application/json
      1462ms 30/Mar/2009:17:23:08 +0200 200 GET /libs/wcm/content/welcome.html text/html; charset=utf-8

Möglicherweise müssen Sie die einzelnen request.log-Dateien verketten, falls Sie diesen Vorgang auf ein großes Datenbeispiel anwenden möchten.

Apache Bench

Um die Auswirkungen von Sonderfällen (z. B. Bereinigung usw.) zu minimieren, wird empfohlen, ein Tool wie apachebench zu verwenden (siehe z. B. die ab-Dokumentation), um Speicherlecks zu identifizieren und Antwortzeiten selektiv zu analysieren.

Apache Bench kann wie folgt verwendet werden:

$ ab -c 5 -k -n 1000 "http://localhost:4503/content/geometrixx/en/company.html"
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, https://www.zeustech.net/
Licensed to The Apache Software Foundation, https://www.apache.org/

Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests

Server Software: Day-Servlet-Engine/4.1.52
Server Hostname: localhost
Server Port: 4503

Document Path: /content/geometrixx/en/company.html
Document Length: 24127 bytes

Concurrency Level: 5
Time taken for tests: 69.766 seconds
Complete requests: 1000
Failed requests: 998
(Connect: 0, Receive: 0, Length: 998, Exceptions: 0)
Write errors: 0
Keep-Alive requests: 0
Total transferred: 24160923 bytes
HTML transferred: 24010923 bytes
Requests per second: 14.33 /sec (mean)
Time per request: 348.828 [ms] (mean)
Time per request: 69.766 [ms] (mean, across all concurrent requests)
Transfer rate: 338.20 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 3.9 0 58
Processing: 138 347 568.5 282 8106
Waiting: 137 344 568.1 281 8106
Total: 139 348 568.4 283 8106

Percentage of the requests served within a certain time (ms)
50% 283
66% 323
75% 356
80% 374
90% 439
95% 512
98% 1047
99% 1132
100% 8106 (longest request)

Die obigen Zahlen stammen von einem MacBook Pro-Laptop (Mitte 2010), der auf die Unternehmensseite von Geometrixx zugreift, wie sie in einer Standardinstallation von AEM enthalten ist. Die Seite ist sehr einfach aufgebaut, aber nicht für Leistung optimiert.

apachebench zeigt auch die durchschnittliche Zeit pro Anforderung für alle gleichzeitigen Anfragen an; siehe Time per request: 54.595 [ms](Durchschnitt aller gleichzeitigen Anfragen). Sie können den Parameterwert für parallele Verarbeitung -c (Anzahl mehrerer gleichzeitig auszuführender Anfragen) ändern, um die Auswirkungen anzuzeigen.

Anforderungszähler

Informationen zum Anforderungs-Traffic (Anzahl der Anforderungen in einem bestimmten Zeitraum) geben Ihnen Aufschluss über die Last auf der Instanz. Sie können diese Informationen aus request.log extrahieren. Mit Zählern können Sie Daten jedoch automatisch erfassen und Folgendes analysieren:

• Erhebliche Unterschiede bei Aktivitäten (z. B. „viele Anforderungen“ im Vergleich zu „geringer Aktivität“)
• Ob eine Instanz nicht verwendet wird
• Alle Neustarts (Zähler wird auf 0 zurückgesetzt)

Um die Datenerfassung zu automatisieren, können Sie auch Anforderungsfilter installieren, sodass ein Zähler bei jeder Anforderung erhöht wird. Mehrere Zähler können für verschiedene Zeiträume verwendet werden.

Informationen können erfasst werden, um Folgendes anzuzeigen:

• Wesentliche Veränderungen der Aktivität
• Eine redundante Instanz
• Alle Neustarts (der Zähler wird auf 0 zurückgesetzt)

HTML-Kommentare

Es wird empfohlen, dass jedes Projekt html comments zur Server-Leistung enthält. Es gibt viele gute Beispiele. Öffnen Sie eine Seite, zeigen Sie den Quelltext an und scrollen Sie zum Ende, dann wird ein Code wie der Folgende angezeigt:

</body>
 </html>
        <!--
        Page took 58 milliseconds to be rendered by server
         -->

Leistungsüberwachung mit JConsole

Der Tool-Befehl jconsole ist bei JDK verfügbar.

1. Starten Sie Ihre AEM-Instanz.

2. Führen Sie jconsole. aus.

3. Wählen Sie Ihre AEM-Instanz und Verbinden.

4. Doppelklicken Sie im Programm Local auf com.day.crx.quickstart.Main. Standardmäßig wird die folgende Übersicht angezeigt:

   

   Anschließend können Sie weitere Optionen auswählen.

Leistungsüberwachung mit (J)VisualVM

Ab JDK 1.6 ist der Tool-Befehl jvisualvm verfügbar. Wenn Sie JDK 1.6 installiert haben, können Sie folgende Schritte ausführen:

1. Starten Sie Ihre AEM-Instanz.

   HINWEIS

   Wenn Sie Java 5 verwenden, können Sie das Argument -Dcom.sun.management.jmxremote zur Java-Befehlszeile, mit der JVM gestartet wird, hinzufügen. JMX ist bei Java 6 standardmäßig aktiviert.

2. Führen Sie einen der beiden Befehle aus:

   • jvisualvm: im Ordner „bin“ von JDK 1.6 (getestete Version)
   • visualvm: kann von VisualVM heruntergeladen werden (allerneueste Version)

3. Doppelklicken Sie im Programm Local auf com.day.crx.quickstart.Main. Standardmäßig wird die folgende Übersicht angezeigt:

   

   Danach können Sie noch weitere Optionen, einschließlich „Monitor“ auswählen:

   

Sie können dieses Tool zum Generieren von Thread-Dumps und Heap-Dump Speicherabbildern verwenden. Diese Informationen werden häufig vom technischen Support-Team angefordert.

Informationserfassung

Wenn Sie möglichst viele Informationen zur Installation haben, ist es einfacher herauszufinden, was die Leistungsänderung verursacht hat und ob diese Änderungen gerechtfertigt sind. Diese Metriken müssen in regelmäßigen Abständen erfasst werden, sodass Sie signifikante Änderungen sofort sehen.

Die folgenden Informationen können hilfreich sein:

• Wie viele Autoren arbeiten mit dem System?
• Wie viele Seiten werden im Durchschnitt pro Tag aktiviert?
• Wie viele Seiten unterhalten Sie derzeit auf diesem System?
• Falls Sie MSM verwenden, wie hoch ist die durchschnittliche Anzahl der Rollouts pro Monat?
• Wie viele Live Copies pro Monat gibt es im Durchschnitt?
• Falls Sie AEM Assets verwenden, wie viele Assets verwalten Sie derzeit in Assets?
• Wie groß sind die Assets im Durchschnitt?
• Wie viele Vorlagen werden derzeit verwendet?
• Wie viele Komponenten werden derzeit verwendet?
• Wie viele Anforderungen pro Stunde erfolgen zu Spitzenzeiten auf dem Autorensystem?
• Wie viele Anforderungen pro Stunde erfolgen zu Spitzenzeiten auf dem Veröffentlichungssystem?

Wie viele Autoren arbeiten mit dem System?

Um die Anzahl der Autoren anzuzeigen, die das System seit der Installation verwendet haben, verwenden Sie folgende Befehlszeile:

cd <cq-installation-dir>/crx-quickstart/logs
cut -d " " -f 3 access.log | sort -u | wc -l

Um die Anzahl der Autoren anzuzeigen, die an einem bestimmten Tag mit dem System arbeiten, verwenden Sie:

grep "<date>" access.log | cut -d " " -f 3 | sort -u | wc -l

Wie viele Seiten werden im Durchschnitt pro Tag aktiviert?

Um die Gesamtzahl der Seitenaktivierungen ab der Serverinstallation anzuzeigen, führen Sie eine Repository-Abfrage aus; via CRXDE – Tools – Abfrage:

• Typ XPath

• Pfad /

• Abfrage //element(*, cq:AuditEvent)[@cq:type='Activate']

Ermitteln Sie die Anzahl der Tage seit der Installation, um den Durchschnitt zu berechnen.

Wie viele Seiten unterhalten Sie derzeit auf diesem System?

Um die Anzahl der aktuellen Seiten auf dem Server anzuzeigen, führen Sie eine Repository-Abfrage aus; via CRXDE – Tools – Abfrage:

• Typ XPath

• Pfad /

• Abfrage //element(*, cq:Page)

Falls Sie MSM verwenden, wie hoch ist die durchschnittliche Anzahl der Rollouts pro Monat?

Um die Gesamtzahl der Rollouts ab der Installation anzuzeigen, verwenden Sie eine Repository-Abfrage über CRXDE – Tools – Abfrage:

• Typ XPath

• Pfad /

• Abfrage //element(*, cq:AuditEvent)[@cq:type='PageRolledOut']

Ermitteln Sie die Anzahl der Monate seit der Installation, um den Durchschnitt zu berechnen.

Wie viele Live Copies pro Monat gibt es im Durchschnitt?

Um die Gesamtzahl der Live Copies ab der Installation anzuzeigen, verwenden Sie eine Repository-Abfrage über CRXDE – Tools – Abfrage:

• Typ XPath

• Pfad /

• Abfrage //element(*, cq:LiveSyncConfig)

Ermitteln Sie erneut die Anzahl der Monate seit der Installation, um den Durchschnitt zu berechnen.

Falls Sie AEM Assets verwenden, wie viele Assets verwalten Sie derzeit in Assets?

Um anzuzeigen, wie viele DAM-Assets Sie derzeit unterhalten, verwenden Sie eine Repository-Abfrage über CRXDE – Tools – Abfrage:

• Typ XPath

• Pfad /

• Abfrage /jcr:root/content/dam//element(*, dam:Asset)

Wie groß sind die Assets im Durchschnitt?

Um die Gesamtgröße des Ordners /var/dam zu ermitteln:

1. Verwenden Sie WebDAV, um das Repository dem lokalen Dateisystem zuzuordnen.

2. Verwenden Sie folgende Befehlszeile:

   cd /Volumes/localhost/var
   du -sh dam/
   

   Um die durchschnittliche Größe zu berechnen, müssen Sie die Gesamtgröße durch die Anzahl der Assets im Ordner /var/dam (oben ermittelt) teilen.

Wie viele Vorlagen werden derzeit verwendet?

Um die Anzahl der aktuellen Vorlagen auf dem Server anzuzeigen, führen Sie eine Repository-Abfrage aus; via CRXDE – Tools – Abfrage:

• Typ XPath

• Pfad /

• Abfrage //element(*, cq:Template)

Wie viele Komponenten werden derzeit verwendet?

Um die Anzahl der aktuellen Komponenten auf dem Server anzuzeigen, führen Sie eine Repository-Abfrage aus; via CRXDE – Tools – Abfrage:

• Typ XPath

• Pfad /

• Abfrage //element(*, cq:Component)

Wie viele Anforderungen pro Stunde erfolgen zu Spitzenzeiten auf dem Autorensystem?

Bestimmen Sie die Anforderungen pro Stunde auf dem Autorensystem zu Spitzenzeiten:

1. Um die Gesamtzahl der Anforderungen seit der Installation zu ermitteln, verwenden Sie folgende Befehlszeile:

   cd <cq-installation-dir>/crx-quickstart/logs
   grep -R "\->" request.log | wc -l
   

2. Um die Start- und Enddaten zu ermitteln, verwenden Sie:

   vim request.log
   G / 1G: for the last/first lines
   

   Verwenden Sie diese Werte, um die Anzahl der Stunden seit der Installation und dann die durchschnittliche Anzahl der Anforderungen pro Stunde zu berechnen.

Wie viele Anforderungen pro Stunde erfolgen zu Spitzenzeiten auf dem Veröffentlichungssystem?

Wiederholen Sie die obigen Schritte auf der Veröffentlichungsinstanz.

Analyse spezifischer Szenarien

Im Folgenden finden Sie eine Liste mit Vorschlägen, was Sie überprüfen sollten, falls Sie gewisse Leistungsprobleme bemerken. Die Liste ist (leider) nicht vollständig.

CPU bei 100 %

Wenn die CPU-Auslastung des Systems ständig bei 100 % liegt, sehen Sie in folgender Dokumentation nach:

• Wissensdatenbank:

  • Analysieren langsamer und blockierter Prozesse

Unzureichender Speicher

Fehler dieser Art sollten zwar bereits bei der Entwicklung und beim Testen bemerkt werden, können aber in bestimmten Szenarien übersehen werden.

Falls das System nicht genügend Speicher hat, kann sich dies auf verschiedene Weise bemerkbar machen, u. a. durch Leistungsbeeinträchtigungen und Fehlermeldungen mit folgendem Subtext:

java.lang.OutOfMemoryError

In diesen Fällen müssen Sie Folgendes überprüfen:

• Die zum Starten von AEM verwendeten JVM-Einstellungen

• Wissensdatenbank:

  • Analysieren von Speicherproblemen

Festplatten-I/O

Falls das System keine Festplattenkapazität mehr hat oder Sie Festplatten-Trashing bemerken, überprüfen Sie Folgendes:

• Haben Sie die Erfassung von Debugging-Daten deaktiviert? Diese Option kann in verschiedenen Komponenten konfiguriert werden, u. a.:

  • Apache Sling JSP Script Handler
  • Apache Sling Java Script Handler
  • Apache Sling Logging-Konfiguration
  • CQ HTML-Bibliotheks-Manager
  • CQ WCM Debug-Filter
  • Protokollierungen

• Haben Sie die Versionsbereinigung deaktiviert?

• Wissensdatenbank:

  • Zu viele geöffnete Dateien
  • Journalling verbraucht zu viel Festplattenspeicher

Normale Leistungsbeeinträchtigung

Falls Sie nach jedem Neustart (ggf. eine Woche oder mehr nach dem Neustart) eine Leistungsverschlechterung der Instanz bemerken, können Sie Folgendes überprüfen:

• Unzureichender Speicher

• Wissensdatenbank:

  • Nicht beendete Sitzungen

JVM-Optimierung

Java Virtual Machine (JVM) ist im Hinblick auf die Optimierung sehr verbessert worden (insbesondere seit Java 7). Daher sind eine vernünftige feste JVM-Größe und die Verwendung der Standardeinstellungen oft ausreichend.

Falls die Standardeinstellungen nicht geeignet sind, ist es wichtig, eine Methode festzulegen, um die GC-Leistung zu überwachen und zu bewerten, bevor Sie JVM optimieren. Überprüfen Sie z. B. Faktoren wie die Heap-Größe, Algorithmen und dergleichen.

Einige der Optionen sind:

• VerboseGC:

  -verbose:gc \
   -Xloggc:$LOGS/verbosegc.log \
   -XX:+PrintGCDetails \
   -XX:+PrintGCDateStamps
  

Das entsprechende Protokoll kann mit einem GC-Visualizer erfasst werden:

[https://www.ibm.com/developerworks/library/j-ibmtools2/](https://www.ibm.com/developerworks/library/j-ibmtools2/)

Oder mit JConsole:

• Diese Einstellungen gelten für eine JMX-Verbindung vom Typ „wide open“:

  -Dcom.sun.management.jmxremote \
   -Dcom.sun.management.jmxremote.port=8889 \
   -Dcom.sun.management.jmxremote.authenticate=false \
   -Dcom.sun.management.jmxremote.ssl=false
  

• Stellen Sie dann mit JConsole eine Verbindung zu JVM her; siehe:
  [https://docs.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html](https://docs.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html)

Dies ist hilfreich, wenn Sie herausfinden möchten, wie viel Arbeitsspeicher belegt ist, welche GC-Algorithmen verwendet werden, wie lange diese ausgeführt werden und welche Auswirkung dies auf die Anwendungsleistung hat. Ohne diese Daten bleibt die Optimierung dem Zufall überlassen.