Sie sehen sich Hilfeinhalte der folgenden Version an:

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 Besonderheiten 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 die Problemberichterstattung 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 gering ist.
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.

Vorsicht:

Wenn Sie Sicherungskopien der Produktionsinstanzen erstellt haben, müssen Sie Tests durchführen, um sicherzustellen, dass die Sicherungskopie erfolgreich wiederhergestellt werden kann.

Andernfalls ist das Backup womöglich nutzlos (im schlimmsten Fall).

Hinweis:

Weitere Informationen zur Backup-Leistung finden Sie im Abschnitt Backup-Leistung.

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 erstein Backup des gesamten Repositorys erstellen und dann folgende Schritte ausführen:

  1. AEM anhalten.

  2. Erstellen Sie ein vollständiges Backup von <cq-installation-dir> vom Dateisystem aus.

Vorsicht:

Falls Sie einen Anwendungsserver eines Drittanbieters verwenden, gibt es möglicherweise zusätzliche Ordner an anderen Speicherorten, die Sie ebenfalls sichern müssen. Informationen dazu, wie Sie Anwendungsserver installieren, finden Sie unter Installieren von AEM mit einem Anwendungsserver.

Vorsicht:

Das inkrementelle Sichern des Dateidatenspeichers wird unterstützt. Wenn Sie inkrementelle Backups anderer Komponenten (z. B. der Lucene-Indizes) erstellen möchten, stellen Sie sicher, dass gelöschte Dateien auch im Backup als gelöscht markiert sind.

Hinweis:

Die Festplattenspiegelung kann als Sicherungsmethode eingesetzt werden.

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 ToolVersionsbereinigung 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:

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

screen_shot_2012-03-15at14418pm

Startpfad

Ein absoluter Pfad, an dem die Bereinigung ausgeführt werden muss. Sie können den Startpfadauswä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 der zu speichernden Versionen

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

Maximales Versionsalter

Das Höchstalter 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.

Vorsicht:

Bereinigte Knoten können ohne Wiederherstellung des Repository nicht zurückgesetzt werden. Da eine fehlerfreie Konfiguration sehr wichtig ist, empfiehlt es sich, vor einer Bereinigung immer einen Probelauf durchzuführen.

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 gibt an, dass es sich um die aktuelle Version handelt.
  • 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.
global_version_screenshot

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-Installationsverzeichnis>/crx-quickstart/logs/
  • <CQ-Installationsverzeichnis>/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}.jjjj-MM-tt umbenannt. Beispielsweise wird die aktuelle Protokolldatei am 11. Juni 2010 umbenannt in error.log-2010-07-10 und anschließend wird eine neue error.log 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.

Hinweis:

Wenn Sie Ihre AEM-Installation aktualisieren, verbleiben vorhandene Protokolldateien, die nicht mehr von AEM verwendet werden, auf der Festplatte. Sie können diese ohne Risiko löschen. Alle neuen Protokolleinträge werden in die neuen Protokolldateien geschrieben.

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 Zugriffsanforderungen 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 dynamische Medien aktiviert sind. 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 Zugriffsanforderungen zusammen mit der Antwort registriert.
    • s7access--<dd>-<mm>-<yyyy>.log
      Dieses Protokoll wird nur verwendet, wenn dynamische Medien aktiviert sind. Im Protokoll „s7access“ werden alle Anforderungen an dynamische Medien über /is/image und /is/content aufgezeichnet.
    • stderr.log
      Enthält Fehlermeldungen (ebenfalls mit unterschiedlichem Schweregrad), die beim Starten generiert werden. Standardmäßig wird für die Protokollebene Warnung (WARN) festgelegt
      .
    • stdout.log
      Enthält Protokollmeldungen, die auf Ereignisse beim Starten verweisen.
    • upgrade.log
      Liefert ein Protokoll aller Aktualisierungsvorgänge, das von den Paketen com.day.compat.codeupgrade und com.adobe.cq.upgradesexecutor aus ausgeführt wird.
  • <cq-installation-dir>/crx-quickstart/repository
    • revision.log
      Zeigt Daten des Revisionsjournals an.

Hinweis:

Die Protokolle „ImageServer“ und „s7access“ sind nicht im Paket Alles herunterladen enthalten, das von der Seite system/console/status-Bundlelist aus erstellt wird. Bei Problemen mit dynamischen Medien hängen Sie zu Supportzwecken bitte die Protokolle „ImageServer“ und „s7access“ an. 

Aktivieren der Protokollebene „DEBUG“

Die Standard-Protokollebene (Apache Sling-Protokollierungskonfiguration) ist „Information“, d. h. es werden keine Debugging-Meldungen protokolliert.

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 aktivieren.

Vorsicht:

Legen Sie für das Protokoll nur so lange wie erforderlich „debug“ fest, da eine große Anzahl an Protokolleinträgen erstellt wird, die Ressourcen verbrauchen.

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, die Installation 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 wurde ausgeführt, es sind jedoch Probleme aufgetreten. Das AEM WCM-System funktioniert möglicherweise nicht ordnungsgemäß.
3 Information Die Aktion war erfolgreich.

Erstellen einer benutzerdefinierten Protokolldatei

Hinweis:

Beim Arbeiten mit Adobe Experience Manager haben Sie mehrere Möglichkeiten, die Konfigurationseinstellungen für Dienste zu verwalten. Einzelheiten und empfohlene Vorgehensweisen finden Sie unter Konfigurieren von OSGi.

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/<Projekt-Name>/config.

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

    • Name: org.apache.sling.commons.log.LogManager.factory.config-<Kennung> (da dies eine Protokollierung ist)
      Dabei wird <Kennung> durch freien Text ersetzt, den Sie eingeben (müssen), um die Instanz zu identifizieren (diese Information muss angegeben werden). Beispielsweise 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 die <Kennung> einen eindeutigen Parameter zu verwenden.

  3. Legen Sie die folgenden Eigenschaften des Knotens fest:

    • Name: org.apache.sling.commons.log.file
      Typ: String
      Wert: Geben Sie die Protokolldatei an, z. B. logs/myLogFile.log

    • Name: org.apache.sling.commons.log.names
      Typ: String[] (String + Multi)
      Wert: Geben Sie die OSGi-Dienste an, für die die Protokollierung Meldungen protokollieren soll, beispielsweise alle Folgenden:
      • org.apache.sling
      • org.apache.felix
      • com.day
    • Name: org.apache.sling.commons.log.level
      Typ: String
      Wert: Geben Sie die erforderliche Protokollebene an (debug, info, warn oder error); z. B. debug
    • Konfigurieren Sie ggf. weitere Parameter:
      • Name: org.apache.sling.commons.log.pattern
        Typ: String
        Wert: Geben Sie das erforderliche Muster der Protokollmeldung an, z. B.
        {0,datum,tt.MM.jjjj HH:mm:ss.SSS} *{4}* [{2}] {3} {5}

    Hinweis:

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

    {0} Zeitstempel vom Typ java.util.Date
    {1} Protokollmarkierung
    {2} Name des aktuellen Thread
    {3} Name der Protokollierung
    {4} Protokollebene
    {5} 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-Installationsverzeichnis>/crx-quickstart/logs/thelog.log.

    Und eine Protokolldatei wie:

        ../logs/thelog.log

    wird in folgendes Verzeichnis geschrieben:

        <CQ-Installationsverzeichnis>/logs/
        (neben  <CQ-Installationsverzeichnis>/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/<Projekt-Name>/config einen Knoten für die neue Apache Sling Logging-Writer-Konfiguration:

    • Name: org.apache.sling.commons.log.LogManager.factory.writer-<Kennung> (da dies ein Writer ist)
      Wie bei der Protokollierung wird der Parameter <Kennung> durch freien Text ersetzt, den Sie eingeben (müssen), um die Instanz zu identifizieren (diese Information muss angegeben werden). Beispielsweise 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 die <Kennung> einen eindeutigen Parameter zu verwenden.

    Legen Sie die folgenden Eigenschaften des Knotens fest:

    • Name: org.apache.sling.commons.log.file
      Typ: String
      Wert: Geben Sie die gleiche Protokolldatei wie in der Protokollierung an;
                beispielsweise ../logs/myLogFile.log.
    • Konfigurieren Sie ggf. weitere Parameter:
      • Name: org.apache.sling.commons.log.file.number
        Typ: Long
        Wert: Geben Sie die Anzahl der Protokolldateien an, 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 '.'dd.MM.yyyy

    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 Standard ist '.'yyyy-MM-dd (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 von dem Gebietsschema ab).
      '.'dd.MM.yyyy 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 reinen Text durch einzelne Anführungszeichen (' ') schützen;
              dadurch wird verhindert, dass bestimmte Zeichen als Musterzeichenfolge 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; wie z. B. 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.

    screen_shot_2012-02-02at43601pm
  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:

screen_shot_2012-02-13at50346pm

Ü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 aktivierten Warteschlangen sollten den Status Im Leerlauf oder Aktiv aufweisen, was einem normalem Betrieb entspricht. Keine der Warteschlangen sollte den Status Blockiert 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:

    chlimage_1

    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 (zu aktivieren, deaktivieren) sowie den der zugrunde liegenden Warteschlange (aktiv, leer, blockiert) 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.

Hinweis:

Spezifische Konfigurationen, die die Leistung verbessern, können ebenfalls überprüft 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.  
Applikation 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): Ctrl-Break

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.

Rufen Sie 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 <Anforderungen> -c <parallele Verarbeitung> <url>

Siehe Apache Bench und die ab man-Seite für weitere Einzelheiten.

Rechercheanalyse   Führen Sie Suchabfragen offline aus, ermitteln Sie die Antwortzeit der Abfrage, testen und bestätigen Sie den Ergebnissatz.
JMeter Last- und Funktionstest. http://jakarta.apache.org/jmeter/
JProfiler Detaillierte CPU- und Speicherprofilerstellung. http://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 der Wert ?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 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-Installationsverzeichnis>/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 beinhaltet verschiedene Hilfe-Tools unter:
    <CQ-Installationsverzeichnis>/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, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://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 Anforderungen an; siehe Time per request: 54.595 [ms] (Durchschnitt aller gleichzeitigen Anforderungen). Sie können den Parameterwert für parallele Verarbeitung -c (Anzahl mehrerer gleichzeitig auszuführender Anforderungen) ä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-Kommentare zur Serverleistung 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 in der lokalen Anwendung auf com.day.crx.quickstart.Main. Standardmäßig wird die folgende Übersicht angezeigt:

    chlimage_1

    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 -Dcom.sun.management.jmxremote-Argument zur Java-Befehlszeile hinzufügen, mit der JVM gestartet wird. 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 in der lokalen Anwendung auf com.day.crx.quickstart.Main. Standardmäßig wird die folgende Übersicht angezeigt:

    chlimage_1

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

    chlimage_1

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

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 anzuzeigen:

  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:

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:

Festplatten-I/O

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

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:

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:

http://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:
    http://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.

Hinweis:

Informationen zu Oracle VM finden Sie unter:

http://docs.oracle.com/javase/7/docs/technotes/guides/vm/server-class.html

Dieses Werk unterliegt den Bedingungen der Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.  Twitter™- und Facebook-Beiträge fallen nicht unter die Bedingungen der Creative Commons-Lizenz.

Rechtliche Hinweise   |   Online-Datenschutzrichtlinie