Überwachen und Verwalten der Adobe Experience Manager-Instanz monitoring-and-maintaining-your-aem-instance

Nach der Bereitstellung Ihrer AEM-Instanzen müssen Sie deren Betrieb, Leistung und Integrität überwachen und aufrechterhalten.

Um potenzielle Probleme erkennen zu können, müssen Sie unbedingt wissen, wie Ihr System unter normalen Bedingungen aussieht und sich verhält. Dies lässt sich am besten durch die Überwachung des Systems und das Sammeln von Informationen im Laufe der Zeit erreichen.

Backups backups

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

Ihr Unternehmen verfügt wahrscheinlich über eine Backup-Richtlinie, der Sie folgen. Weitere Aspekte, was und wann gesichert werden sollte, sind unter anderem die folgenden:

Häufig wird ein vollständiges Backup in regelmäßigen Abständen durchgeführt (z. B. täglich, wöchentlich oder monatlich), wobei inkrementelle Backups dazwischen liegen (z. B. stündlich, täglich oder wöchentlich).

Erstellen eines Backups Ihrer installierten Software backing-up-your-software-installation

Erstellen Sie nach der Installation oder nach wesentlichen Änderungen der Konfiguration ein Backup Ihrer Software-Installation.

Um diese Aufgabe zu bewältigen, müssen Sie erst ein Backup des gesamten Repositorys erstellen und dann folgende Schritte ausführen:

Erstellen eines Backups Ihres Repositorys backing-up-your-repository

Der Abschnitt Sicherung und Wiederherstellung in der CRX-Dokumentation behandelt alle Fragen im Zusammenhang mit Backups des CRX-Repositorys.

Details zum Erstellen eines „Hot“-Backups im Online-Betrieb 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. 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 overview

Das Tool Versionen bereinigen ist als wöchentliche Wartungsaufgabe verfügbar. Vor der erstmaligen Verwendung muss die Aufgabe hinzugefügt und dann konfiguriert werden. Danach kann sie auf Anfrage oder wöchentlich ausgeführt werden.

Bereinigen von Versionen einer Website purging-versions-of-a-web-site

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

Probelauf – Analyse der Konsole analyzing-the-console

Die klassische Benutzeroberfläche bietet eine Probelauf-Option von:

Der Prozess listet alle Knoten auf, die verarbeitet wurden. Während des Prozesses 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, was Sie finden und wo Sie es finden können.

Arbeiten mit Protokollen working-with-logs

AEM WCM-System zeichnet detaillierte Protokolle auf. Nach dem Entpacken und Aufrufen der Schnellstart-Funktion finden Sie Protokolle an den folgenden Speicherorten:

Rotation von Protokolldateien log-file-rotation

Die Rotation von Protokolldateien bezieht sich auf den Prozess, der das Wachstum der Datei begrenzt, indem regelmäßig eine Datei erstellt wird. In AEM wird eine Protokolldatei mit dem Namen error.log täglich nach den vorgegebenen Regeln rotiert:

Suchen nach Protokolldateien finding-the-log-files

Verschiedene Protokolldateien werden auf dem Datei-Server gespeichert, auf dem Sie AEM installiert haben:

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

Die standardmäßige 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 konfigurieren.

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

DEBUG 3 WebApp Panel: WebApp successfully deployed

Die Protokollebenen lauten wie folgt:

Erstellen einer benutzerdefinierten Protokolldatei 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, https://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 AEM WCM- bzw. OSGi-Ereignisse werden unterschiedliche Auditdatensätze generiert.

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

AEM WCM-Auditdatensätze 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 individuelle Datensätze und die darin enthaltenen Informationen sehen.

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 Audit-Einträge, die Sie in der AEM-Web-Konsole auf der Registerkarte Konfigurationsstatus unter Protokolldateien anzeigen können:

Überwachen der Replikationsagenten monitoring-your-replication-agents

Sie können Ihre Replikations-Warteschlangen überwachen, um zu erkennen, wann eine Warteschlange ausfällt oder blockiert ist – was wiederum auf ein Problem mit einer Publishing-Instanz 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

Die Leistungsoptimierung ist ein interaktiver Prozess, der während der Entwicklung im Mittelpunkt steht. Nach der Bereitstellung wird sie 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 sowie Vorschlägen, wie Sie diese erkennen und beheben können.

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.

Dies kann sich ebenfalls auf alle Ihre Besuchenden oder nur auf eine Untergruppe auswirken.

All diese Informationen müssen erfasst, sortiert und analysiert werden, bevor Sie entweder 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 dieser Tools 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 wertvolle Schlüsse daraus ziehen.

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

Es wird empfohlen, „langsame“ Seiten aus dem request.log zu isolieren und einzeln für eine bessere Leistung zu optimieren. Schließen Sie Leistungsmetriken pro Komponente ein oder verwenden Sie ein Leistungs-Profilierungs-Tool, z. B. [yourkit](https://www.yourkit.com/).

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

Durch Addieren aller GET-Einträge innerhalb bestimmter Zeiträume (z. B. über mehrere 24-Stunden-Zeiträume) können Sie Aussagen zum durchschnittlichen Traffic auf Ihrer Website treffen.

Ü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 wurden aus Gründen der 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. Aus diesen Statistiken können Sie ableiten, welche Seiten oder Seitentypen langsam sind und ob die Gesamtleistung zufriedenstellend ist.

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

Suchanfragen 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 Reaktionszeit ermittelt haben, sollten Sie jedoch auch analysieren, warum die Anfrage die entsprechende Zeit benötigt und was getan werden kann, um die Reaktion 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 Anfragen mit langer Dauer using-rlog-jar-to-find-requests-with-long-duration-times

AEM bietet verschiedene Hilfs-Tools in den folgenden Bereichen:
<cq-installation-dir>/crx-quickstart/opt/helpers

Eines dieser Tools, rlog.jar, kann zum schnellen Sortieren von request.log verwendet werden, indem Anfragen nach Dauer, von der längsten bis zur kürzesten, 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 den Befehl mit der Datei request.log als Parameter ausführen und die ersten zehn Anfragen 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

Verketten Sie die individuellen request.log-Dateien, wenn Sie diesen Vorgang für eine große Datenprobe durchführen müssen.

Apache Bench apache-bench

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

Apache Bench kann wie folgt verwendet werden:

$ ab -c 5 -k -n 1000 "https://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 aus einem standardmäßigen 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.

Die apachebench zeigt auch die durchschnittliche Zeit pro Anfrage für alle gleichzeitigen Anfragen an. So sehen Sie 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.

Anfragezähler request-counters

Informationen zum Anfrage-Traffic (Anzahl der Anfragen während eines bestimmten Zeitraums) dienen als Hinweis auf die Auslastung Ihrer Instanz. Diese Informationen können aus request.log extrahiert werden, wobei die Datenerfassung jedoch 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 Anfrage 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. Wählen Sie eine Seite aus, öffnen Sie die Seitenquelle zur Anzeige und scrollen Sie ganz nach unten. Dort wird Code wie der folgende angezeigt:

</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 6 ist der Tool-Befehl visualvm verfügbar. Nachdem Sie ein JDK installiert haben, können Sie Folgendes tun:

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, kann Ihnen dies unter Umständen helfen, herauszufinden, was zu einer Änderung der Leistung geführt haben könnte und ob diese Änderungen sich begründen lassen. Erfassen Sie diese Metriken in regelmäßigen Abständen, damit Sie signifikante Änderungen direkt 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 folgende Befehlszeile, um die Anzahl der Autorinnen und 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 Autorinnen und 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

Führen Sie eine Repository-Abfrage aus, um die Gesamtzahl der Seitenaktivierungen seit der Server-Installation anzuzeigen. Gehen Sie dafür über 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

Führen Sie eine Repository-Abfrage aus, um die Anzahl der Seiten anzuzeigen, die sich derzeit auf dem Server befinden. Tun Sie dies über 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

Führen Sie eine Repository-Abfrage aus, um die Gesamtzahl der Rollouts seit der Installation zu ermitteln. Gehen Sie dafür über 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. Gehen Sie dafür über 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

Führen Sie eine Repository-Abfrage aus, um die Anzahl der Vorlagen anzuzeigen, die sich derzeit auf dem Server befinden. Gehen Sie dafür über CRXDE – Tools – Abfrage:

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

Führen Sie eine Repository-Abfrage aus, um die Anzahl der Komponenten anzuzeigen, die sich derzeit auf dem Server befinden. Gehen Sie dafür über 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

Um die Anzahl der Anfragen pro Stunde zu ermitteln, die Sie zu Spitzenzeiten auf dem Autorensystem haben:

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.

Analyse 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 zu 100 % ausgelastet ist, lesen Sie Folgendes:

Unzureichender Speicher out-of-memory

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

Wenn Ihrem System der Arbeitsspeicher ausgeht, kann sich dieses Problem auf verschiedene Weise zeigen, beispielsweise durch Leistungseinbußen und Fehlermeldungen, die den Untertext einschließen:

java.lang.OutOfMemoryError

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

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

Wenn Ihrem System der Festplattenspeicher ausgeht oder Sie feststellen, dass die Festplatte überlastet ist, überprüfen Sie Folgendes:

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

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

JVM-Optimierung jvm-tuning

Die Java™ Virtual Machine (JVM) hat sich im Hinblick auf die Optimierung 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. Tun Sie dies, bevor Sie versuchen, die JVM zu optimieren. Dieser Prozess kann Überwachungsfaktoren beinhalten, darunter Heap-Größe, Algorithmus und andere Aspekte.

Häufig gewählt werden beispielsweise:

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:

Hier können Sie sehen, wie viel Arbeitsspeicher belegt ist, welche GC-Algorithmen verwendet werden, wie lange ihre Ausführung dauert und welche Auswirkung dieser Prozess auf die Anwendungsleistung hat. Ohne dies ist jede Optimierung unsystematisch und willkürlich.