Überwachen und Warten Ihrer AEM-Instanz monitoring-and-maintaining-your-aem-instance

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. Dies geschieht am besten durch Überwachung des Systems und Erfassung von Informationen über einen bestimmten Zeitraum.

Backups backups

Es empfiehlt sich, Sicherungen von Folgendem zu übernehmen:

Ihr Unternehmen wird wahrscheinlich über eine Sicherungsrichtlinie verfügen, die Sie befolgen müssen, zusätzliche Überlegungen dazu, was Sie sichern möchten, und wann:

Häufig wird eine vollständige Sicherung in regelmäßigen Abständen (z. B. täglich, wöchentlich oder monatlich) durchgeführt, wobei inkrementelle Sicherungen zwischen (z. B. stündlich, täglich oder wöchentlich) erfolgen.

Sichern der Software-Installation backing-up-your-software-installation

Nach der Installation oder nach wesentlichen Änderungen der Konfiguration sollten Sie eine Sicherungskopie Ihrer Software-Installation erstellen.

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

Repository sichern backing-up-your-repository

Die Sicherung und Wiederherstellung -Abschnitt der CRX-Dokumentation behandelt alle Probleme im Zusammenhang mit Sicherungen des CRX-Repositorys.

Ausführliche Informationen zum Erstellen eines "Hot"-Backups im Internet finden Sie unter Erstellen eines Online-Backups.

Versionsbereinigung version-purging

Das Tool Versionen bereinigen dient zum Bereinigen der Versionen eines Knotens oder einer Hierarchie von Knoten in Ihrem Repository. Ihr Hauptzweck besteht darin, Ihnen zu helfen, die Größe Ihres Repositorys zu reduzieren, indem Sie alte Versionen Ihrer Knoten entfernen.

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. Ihr Hauptzweck besteht darin, Ihnen zu helfen, die Größe Ihres Repositorys zu reduzieren, indem Sie alte Versionen Ihrer Knoten entfernen.

Überblick overview

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 purging-versions-of-a-web-site

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

Analyse der Konsole analyzing-the-console

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:

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

Im Folgenden ein Beispiel:

Arbeiten mit Auditdatensätzen und Protokolldateien working-with-audit-records-and-log-files

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

Arbeiten mit Protokollen working-with-logs

AEM WCM-System zeichnet detaillierte Protokolle auf. Nachdem Sie Quickstart entpackt und gestartet haben, finden Sie Protokolle in:

Protokolldateirotation log-file-rotation

Die Rotation von Protokolldateien bezieht sich auf den Prozess, der das Dateiwachstum begrenzt, indem regelmäßig neue Dateien erstellt werden. In AEM wird die Protokolldatei error.log täglich nach folgenden Regeln rotiert:

Suchen nach Protokolldateien finding-the-log-files

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

Aktivieren der DEBUG-Protokollebene activating-the-debug-log-level

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:

Benutzerdefinierte Protokolldatei erstellen create-a-custom-log-file

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:

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

Auffinden der Auditdatensätze finding-the-audit-records

Auditdatensätze werden als Nachweis darüber aufbewahrt, wer wann welche Aktion vorgenommen hat. Für WCM- und OSGi-Ereignisse werden unterschiedliche Auditdatensätze AEM.

AEM bei der Seitenbearbeitung angezeigte WCM-Auditdatensätze aem-wcm-audit-records-shown-when-page-authoring

AEM von WCM-Auditdatensätzen im Repository aem-wcm-auditing-records-within-the-repository

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

Diese Einträge enthalten dieselben Informationen, die beim Bearbeiten einer Seite angezeigt werden.

OSGi-Auditdatensätze aus der Web-Konsole osgi-audit-records-from-the-web-console

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

Überwachen von Replikationsagenten monitoring-your-replication-agents

Sie können Ihre Replikations-Warteschlangen , um zu erkennen, wann eine Warteschlange ausfällt oder blockiert ist - was wiederum auf ein Problem mit einer Veröffentlichungsinstanz oder einem externen System hinweisen könnte:

So überwachen Sie einen Replikationsagenten:

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.

Überwachung der Leistung monitoring-performance

Leistungsoptimierung ist ein interaktiver Prozess, der während der Entwicklung im Mittelpunkt steht. Nach der Bereitstellung wird sie in der Regel 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.

Leistungsprobleme können aus einer Reihe von Ursachen herrühren, die nichts mit Ihrer Website zu tun haben, darunter vorübergehende Verlangsamungen bei der Verbindungsgeschwindigkeit, CPU-Last und vieles mehr.

Dies kann sich auch auf alle Ihre Besucher oder nur auf eine Untergruppe davon auswirken.

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

Tools zur Leistungsüberwachung und -analyse tools-for-monitoring-and-analyzing-performance

Im Folgenden finden Sie einen kurzen Überblick über einige der verfügbaren Tools zur Leistungsüberwachung und -analyse.

Einige davon hängen von Ihrem Betriebssystem ab.

Interpretieren von request.log interpreting-the-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.

Traffic-Überwachung auf Ihrer Website monitoring-traffic-on-your-website

Das Anfrageprotokoll registriert jede ausgeführte Anfrage sowie die Antwort:

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

Indem Sie alle GET innerhalb eines bestimmten Zeitraums (z. B. über verschiedene Zeiträume von 24 Stunden) auflisten, können Sie Aussagen zum durchschnittlichen Traffic auf Ihrer Website machen.

Überwachen der Antwortzeiten mit request.log monitoring-response-times-with-the-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 werden zur Einfachheit 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:

Mithilfe von kleinen Skripten können Sie die erforderlichen Informationen aus der Protokolldatei extrahieren und die gewünschten Statistiken zusammenstellen. Daraus können Sie erkennen, welche Seiten oder Seitentypen langsam sind und ob die Gesamtleistung zufriedenstellend ist.

Überwachen der Antwortzeiten der Suche mit request.log monitoring-search-response-times-with-the-request-log

Suchanforderungen werden auch 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

Sie können also wie oben beschrieben Skripte verwenden, um die relevanten Informationen zu extrahieren und Statistiken zu erstellen.

Nachdem Sie die Antwortzeit ermittelt haben, müssen Sie möglicherweise analysieren, warum die Anfrage die Zeit benötigt und was getan werden kann, um die Antwort zu verbessern.

Überwachen der Anzahl und Auswirkung gleichzeitiger Benutzer monitoring-the-number-and-impact-of-concurrent-users

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 Skripte verwendet werden, um Ergebnisse aus der Protokolldatei zu extrahieren:

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 zum Suchen von Anforderungen mit langer Dauer using-rlog-jar-to-find-requests-with-long-duration-times

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 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 request-counters

Informationen zum Anforderungs-Traffic (Anzahl der Anfragen während eines bestimmten Zeitraums) geben Ihnen einen Hinweis auf die Belastung Ihrer Instanz. Diese Informationen können aus request.log, obwohl die Datenerfassung mithilfe von Zählern automatisiert wird, damit Sie Folgendes sehen können:

Um die Datenerfassung zu automatisieren, können Sie auch einen RequestFilter installieren, um bei jeder Anforderung einen Zähler zu erhöhen. Für verschiedene Zeiträume können mehrere Zähler verwendet werden.

Die erfassten Informationen können verwendet werden, um Folgendes anzugeben:

HTML Kommentare html-comments

Es wird empfohlen, dass jedes Projekt html comments zur Server-Leistung enthält. Es gibt viele gute öffentliche Beispiele. eine Seite auswählen, die Seitenquelle zum Anzeigen öffnen und zum unteren Rand blättern, z. B. der folgende Code:

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

Überwachen der Leistung mit JConsole monitoring-performance-using-jconsole

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

Leistungsüberwachung mit (J)VisualVM monitoring-performance-using-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:

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

Informationserfassung information-collection

Wenn Sie möglichst viel über Ihre Installation wissen, können Sie feststellen, was möglicherweise zu Leistungsänderungen geführt 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? how-many-authors-are-working-with-the-system

Verwenden Sie die Befehlszeile, um die Anzahl der Autoren anzuzeigen, die das System seit der Installation verwendet haben:

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

So zeigen Sie die Anzahl der Autoren an, die an einem bestimmten Datum arbeiten:

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

Wie viele Seiten werden im Durchschnitt pro Tag aktiviert? what-is-the-average-number-of-page-activations-per-day

Um die Gesamtzahl der Seitenaktivierungen seit der Serverinstallation anzuzeigen, verwenden Sie eine Repository-Abfrage. via CRXDE - Tools - Abfrage:

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

Wie viele Seiten unterhalten Sie derzeit auf diesem System? how-many-pages-do-you-currently-maintain-on-this-system

Verwenden Sie eine Repository-Abfrage, um die Anzahl der Seiten anzuzeigen, die sich derzeit auf dem Server befinden. via CRXDE - Tools - Abfrage:

Falls Sie MSM verwenden, wie hoch ist die durchschnittliche Anzahl der Rollouts pro Monat? if-you-use-msm-what-is-the-average-number-of-rollouts-per-month

Verwenden Sie eine Repository-Abfrage, um die Gesamtzahl der Rollouts seit der Installation zu ermitteln. via CRXDE - Tools - Abfrage:

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

Wie viele Live Copies pro Monat gibt es im Durchschnitt? what-is-the-average-number-of-live-copies-per-month

Verwenden Sie eine Repository-Abfrage, um die Gesamtzahl der Live Copies seit der Installation zu ermitteln. via CRXDE - Tools - Abfrage:

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? if-you-use-aem-assets-how-many-assets-do-you-currently-maintain-in-assets

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

Wie groß sind die Assets im Durchschnitt? what-is-the-average-size-of-the-assets

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

Wie viele Vorlagen werden derzeit verwendet? how-many-templates-are-currently-used

Verwenden Sie eine Repository-Abfrage, um die Anzahl der Vorlagen anzuzeigen, die sich derzeit auf dem Server befinden. via CRXDE - Tools - Abfrage:

Wie viele Komponenten werden derzeit verwendet? how-many-components-are-currently-used

Verwenden Sie eine Repository-Abfrage, um die Anzahl der Komponenten anzuzeigen, die sich derzeit auf dem Server befinden. via CRXDE - Tools - Abfrage:

Wie viele Anforderungen pro Stunde erfolgen zu Spitzenzeiten auf dem Autorensystem? how-many-requests-per-hour-do-you-have-on-the-author-system-at-peak-time

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

Wie viele Anforderungen pro Stunde erfolgen zu Spitzenzeiten auf dem Veröffentlichungssystem? how-many-requests-per-hour-do-you-have-on-the-publish-system-at-peak-time

Wiederholen Sie die obigen Schritte auf der Veröffentlichungsinstanz.

Analysieren spezifischer Szenarien analyzing-specific-scenarios

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 % cpu-at

Wenn die CPU Ihres Systems ständig bei 100 % ausgeführt wird, lesen Sie Folgendes:

Unzureichender Speicher out-of-memory

Obwohl solche Fehler während der Entwicklung und Tests erkannt werden sollten, können sich bestimmte Szenarien durchschlagen.

Wenn Ihrem System der Arbeitsspeicher ausgeht, kann dies auf verschiedene Weise angezeigt werden, einschließlich Leistungsbeeinträchtigung und Fehlermeldungen, einschließlich des Untertexts:

java.lang.OutOfMemoryError

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

Datenträger-E/A disk-i-o

Wenn Ihrem System der Speicherplatz ausgeht oder Sie feststellen, dass der Datenträger bestickt wird, lesen Sie Folgendes:

Regelmäßige Leistungsbeeinträchtigung regular-performance-degradation

Wenn die Leistung Ihrer Instanz nach jedem Neustart (manchmal eine Woche oder später) beeinträchtigt wird, kann Folgendes überprüft werden:

JVM-Optimierung jvm-tuning

Die Java Virtual Machine (JVM) hat sich im Hinblick auf die Optimierung deutlich verbessert (insbesondere seit Java 7). Daher ist es oft sinnvoll, eine angemessene feste JVM-Größe anzugeben und die Standardwerte zu verwenden.

Wenn die Standardeinstellungen nicht geeignet sind, ist es wichtig, eine Methode zur Überwachung und Bewertung der GC-Leistung festzulegen, bevor versucht wird, die JVM zu optimieren. Dazu können Überwachungsfaktoren wie die Heap-Größe, Algorithmen und andere Aspekte gehören.

Einige häufige Optionen sind:

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:

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.