Dokumentation

AEM 6.x | Tipps zur Leistungsoptimierung

Last update: Tue Jul 16 2024 00:00:00 GMT+0000 (Coordinated Universal Time)

Erfahren Sie mehr über effektive Strategien und Tipps zur Leistungsoptimierung von Adobe Experience Manager (AEM), Lasttests, JVM-Parametern und Cache-Optimierung.

Beschreibung description

Umgebung

  • Adobe Experience Manager 6.4
  • Adobe Experience Manager 6.5

Problem/Symptome

Die Antwortzeit ist schlecht, wenn Autoren Inhalte bearbeiten oder Websites nur langsam auf Besucheranfragen reagieren.

Diese Tipps zur Leistungsoptimierung können dazu beitragen, Abfragen und Leistung zu beschleunigen.

Ursache

Die folgenden Faktoren beeinflussen Leistungsprobleme in AEM:

  • Unsachgemäßes Design
  • Anwendungscode
  • Nicht zwischenspeichern
  • Fehlerhafte I/O-Konfiguration der Festplatte
  • Speichergröße
  • Netzwerkbandbreite und -latenz
  • AEM auf einigen ausgewählten Windows 2008- und 2012-Versionen installiert, bei denen die Speicherverwaltung ein Problem darstellt
  • Das Ändern von nativen Konfigurationen wie unten beschrieben kann zur Verbesserung der Leistung in AEM beitragen.

Auflösung resolution

Leistungsprobleme verhindern

Im Folgenden finden Sie einige Schritte, mit denen Sie sicherstellen können, dass Leistungsprobleme gefunden und behoben werden, bevor sie sich auf Ihre Benutzer auswirken:

  1. Implementieren und führen Sie Lasttests durch, die realistische Szenarien sowohl in der Autoren- als auch in der Veröffentlichungsinstanz simulieren. Die Ermittlung und Definition der erwarteten Belastung ist ein wichtiger Schritt in diesem Prozess. Auf diese Weise können Sie demonstrieren, ob die AEM-Anwendung, Architektur und AEM Installation gut funktioniert, sobald sie in einer Produktionsumgebung verfügbar ist.
    Die Ergebnisse dieser Übung helfen dabei festzustellen, ob es eine Fehlkonfiguration, ein Anwendungsproblem, eine Größenanpassung, ein Hardwareproblem oder ein anderes Problem gibt, das sich auf die Systemleistung auswirkt. Siehe auch die Leistungsrichtlinien und die Überwachungsrichtlinien.

  2. Zusätzlich zu den Belastungstests hilft Stresstests, die maximale Belastung zu definieren, die das System bewältigen kann. Dieser Test kann Ihnen bei der Vorbereitung auf Traffic-Spitzen helfen. Weitere Informationen zu Leistungstests finden Sie hier.

  3. Installieren Sie die empfohlenen AEM Service Packs, Cumulative Fix Packs und Hotfixes: Adobe Experience Manager-Versionsupdates.

  4. Wenn Sie Windows-Server verwenden, lesen Sie diesen Artikel.

  5. Wenn Sie große Mengen von Assets (Bilder, Videos usw.) in AEM laden möchten, achten Sie darauf, die Best Practices für Assets anzuwenden.

  6. Bereitstellung von ausreichend RAM und Vermeidung von IO-Sättigung
    Wenn Sie beabsichtigen, die Produktion in einem beliebigen Maßstab auszuführen, sollte die Linux-Umgebung mit so viel RAM ausgestattet werden, wie die Segment-Tar-Dateien zwischen der Offline-Komprimierung (oder Online-Komprimierungsspitzen) anwachsen. Darüber hinaus verhindert Folgendes die IO-Sättigung.

    • Separate Betriebssystem-, Daten- und Protokollierungsdatenträger
    • Stellen Sie Datendisketten mit Noatime bereit.
    • Legen Sie die Read-Ahead-Puffer auf dem Datenspeicher auf 32 fest.
    • Idealerweise sollten Sie XFS über ext4 auf den Datenträgern verwenden.
    • Wenn RedHat in einer VM ausgeführt wird, stellen Sie sicher, dass der Entropy-Pool immer > 1K Bit beträgt (verwenden Sie bei Bedarf rngtools).

  7. Deaktivieren von Transparent Huge Pages unter Linux
    AEM führt feinkörnige Lese-/Schreibvorgänge durch, während Linux Transparent Huge Pages für große Vorgänge optimiert sind. Daher wird empfohlen, bei Verwendung von Mongo oder Tar-Speicher die Option Transparent Huge Pages zu deaktivieren.

  8. Verlaufs-Workflows aktivieren
    Übergangs-Workflows können für alle Workflows verwendet werden, die:

    • werden oft ausgeführt.
    • den Workflow-Verlauf nicht benötigen.

    Sie werden in diesen Situationen eine Leistungssteigerung bewirken.
    Dieser Anwendungsfall wird in der Regel erfüllt, wenn große Mengen an Assets erfasst werden.
    Befolgen Sie das in Leistungsoptimierung von Assets beschriebene Verfahren.

  9. Anpassen von Sling-Auftragswarteschlangen
    Der Massen-Upload großer Assets ist normalerweise ein sehr ressourcenintensiver Prozess. Standardmäßig entspricht die Anzahl der gleichzeitigen Threads pro Auftragswarteschlange der Anzahl der CPU-Kerne. Daher kann diese Werteinstellung zu einer allgemeinen Leistungsbeeinträchtigung und einem hohen Java-Heap-Verbrauch führen.
    Adobe empfiehlt, 50 % der CPU-Kerne nicht zu überschreiten. Gehen Sie wie folgt vor, um diesen Wert anzupassen: https:/host:port/system/console/configMgr/org.apache.sling.event.jobs.QueueConfiguration
    Setzen Sie queue.maxparallel auf einen Wert, der 50 % der CPU-Kerne des Servers darstellt, der Ihre AEM-Instanz hostet. Setzen Sie beispielsweise für 8 CPU-Kerne den Wert auf 4.

  10. Anpassen des Oak-Repositorys
    Stellen Sie zunächst sicher, dass Sie die neueste Oak-Version für Ihre AEM 6-Instanz installiert haben. Überprüfen Sie die oben erwähnte Seite mit empfohlenen Hotfixes.

Oak-Abfrage-Engine-/Indexoptimierungen

  • Erstellen Sie benutzerdefinierte Oak-Indizes für alle häufig verwendeten Suchabfragen.

    • Informationen zur Analyse langsamer Abfragen finden Sie in diesem Artikel.
    • Erstellen Sie die benutzerdefinierten Indizes unter dem Knoten oak:index für alle Sucheigenschaften, mit denen Sie suchen möchten, indem Sie diesem Artikel folgen.
    • Versuchen Sie für jeden benutzerdefinierten Lucene-basierten Index, die Einstellung includedPaths (String) so festzulegen, dass der Index nur auf bestimmte Inhaltspfade angewendet wird. Schränken Sie dann die anwendbaren Suchen auf die Pfade ein, die im Index enthalten sind.

  • JVM-Parameter
    Fügen Sie diese JVM-Parameter im AEM-Startskript hinzu, um zu verhindern, dass umfassende Abfragen die Systeme überlasten. Beachten Sie, dass es sich hierbei um Standardwerte handelt, die ab AEM 6.3 gelten.

    • Doak.queryLimitInMemory=500000 (siehe auch Oak-Dokumentation)
    • Doak.queryLimitReads=100000 (siehe auch Oak-Dokumentation)
    • Dupdate.limit=250000 (nur für DocumentNodeStore, z. B. MongoMK, RDBMK)

    Die folgende Option kann auch die Leistung verbessern, ändert jedoch die Bedeutung des Ergebnisgrößenaufrufs. Insbesondere werden bei der Berechnung der Größe nur Abfrageeinschränkungen berücksichtigt, die Teil des verwendeten Index sind.
    Darüber hinaus werden ACLs nicht auf die Ergebnisse angewendet, sodass Knoten, die für die aktuelle Sitzung nicht sichtbar sind, weiterhin in der zurückgegebenen Anzahl enthalten sind. Somit kann die zurückgegebene Anzahl höher als die tatsächliche Anzahl an Ergebnissen sein, und die genaue Anzahl kann nur durch Iteration der Ergebnisse bestimmt werden:

    Vorsicht: Die Aktivierung von fastQuerySize führt zu schnelleren Abfrageantworten. AEM gibt jedoch für einige Abfragen ungenaue Ergebniszahlen zurück. Wenn Sie in Ihrer Anwendung auf genaue Ergebniszahlen angewiesen sind, verwenden Sie nicht fastQuerySize.

  • Lucene-Indexkonfiguration
    Öffnen Sie /system/console/configMgr/org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProviderService und

    • CopyOnRead aktivieren (seit AEM 6.2 standardmäßig aktiviert)
    • CopyOnWrite aktivieren (seit AEM 6.2 standardmäßig aktiviert)
    • Aktivieren Sie Indexdateien vorab abrufen (seit AEM 6.2 standardmäßig aktiviert).

    Weitere Informationen zu den verfügbaren Parametern finden Sie unter https://jackrabbit.apache.org/oak/docs/query/lucene.html .
    Da einige Pfade nicht indiziert werden müssen, haben Sie folgende Möglichkeiten:
    Gehen Sie in CRXDE Lite zu /oak:index/lucene, legen Sie eine mehrwertige String-Eigenschaft (String) namens excludedPaths mit den Werten /var, /etc/workflow/instances, /etc/replication fest.

  • Datenspeicher
    Wenn Sie AEM Assets verwenden oder über eine AEM-Anwendung verfügen, die Binärdateien extensiv verwendet, empfiehlt Adobe die Verwendung eines externen Datenspeichers. Die Verwendung eines externen Datenspeichers trägt zur Gewährleistung der maximalen Leistung bei. Detaillierte Anweisungen finden Sie in der 🔗Dokumentation .

Stimmen Sie bei Verwendung eines FileDataStore cacheSizeInMB auf einen Prozentsatz des verfügbaren Heap ab. Ein konservativer Wert beträgt 2 % des maximalen Heap. Beispiel für einen 8 GB großen Heap:

  - maxCachedBinarySize=1048576
  - cacheSizeInMB=164

 Beachten Sie, dass *maxCachedBinarySize* auf 1 MB (1048576) eingestellt ist. Daher werden nur Dateien zwischengespeichert, die maximal 1 MB groß sind. Eine Anpassung dieser Einstellung auf einen kleineren Wert kann ebenfalls sinnvoll sein.

Wenn Sie mit einer großen Anzahl von Binärdateien arbeiten, möchten Sie die Leistung maximieren. Daher empfiehlt Adobe, einen externen Datenspeicher anstelle der standardmäßigen Knotenspeicher zu verwenden. Darüber hinaus empfiehlt Adobe die Abstimmung der folgenden Parameter:

  - maxCachedBinarySize=10485760
  - cacheSizeInMB=4096

 Hinweis: Die Einstellung *cacheSizeInMB* kann dazu führen, dass dem Java-Prozess der Arbeitsspeicher ausgeht, wenn er zu hoch eingestellt ist. Wenn Sie beispielsweise die maximale Heap-Größe auf 8 GB (-Xmx8g) festgelegt haben und erwarten, dass AEM und Ihre Anwendung einen kombinierten Heap von 4 GB verwenden, ist es sinnvoll, cacheSizeInMB auf 82 statt auf 164 festzulegen. Im Bereich von 2-10 % des maximalen Heap ist eine sichere Konfiguration. Adobe empfiehlt jedoch, dass Sie Einstellungen mit Lasttests validieren und gleichzeitig die Speicherauslastung überwachen.

​11. Mongo-Speicheroptimierung

  • MongoBlobStore-Cachegröße: Der Blobstore wird zum Speichern und Lesen großer binärer Objekte verwendet. Intern wird der Speicher mit Cache implementiert, der die Binärdateien in relativ kleinen Blöcken (Daten- oder Hash-Code oder indirekter Hash) aufteilt, sodass jeder Block in den Speicher passt. Bei einer Standardeinrichtung verwendet der MongoBlobStore eine feste Cache-Größe von 16 MB. Erhöhen Sie bei Bereitstellungen, bei denen mehr RAM verfügbar ist und häufig auf Blob-Speicher zugegriffen wird (z. B. bei einem großen Lucene-Index) die Cachegröße. Diese Cachegröße gilt nur, wenn Sie MongoBlobStore (Standard) verwenden, nicht bei Verwendung eines externen Blob Stores.

    • Sie können die Cachegröße (in MB) über die Einstellung blobCacheSize auf DocumentNodeStoreService konfigurieren.
      Beispiel: blobCacheSize=1024
    • Lesen Sie auch AEM-MongoDB checklist.

  • Dokument-Cache-Größe: Um die Leistung beim Lesen von Knoten von MongoDB zu optimieren, müssen Sie die Cachegrößen von DocumentNodeStore anpassen. Die Standardgröße des Caches ist auf 256 MB festgelegt, die auf verschiedene im DocumentNodeStore verwendete Caches verteilt sind. Siehe http://jackrabbit.apache.org/oak/docs/nodestore/documentmk.html#cache

    • Sie können die Cache-Größe (MB) über die Cache-Einstellung in DocumentNodeStoreService konfigurieren. Beispiel: cache=2048.

    • Legen Sie alle folgenden Cache-Konfigurationen in crx-quickstart/install/org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.config fest und laden Sie dann den Test mit verschiedenen Werten, um zu sehen, welche optimale Konfiguration für Ihre Umgebung ist. Beachten Sie, dass der verbleibende Cache-Prozentsatz dem Dokument-Cache zugewiesen wird:

      • cache=2048
      • nodeCachePercentage=35
      • childrenCachePercentage=20
      • diffCachePercentage=30
      • docChildrenCachePercentage=10

    • Bei der obigen Konfiguration belaufen sich die Prozentsätze auf 95 %. Die restlichen 5 % des Caches werden an documentCache übergeben. documentCache = cache - nodeCache - childrenCache - diffCache - docChildrenCache

    • Stellen Sie beim Verteilen der Cache-Prozentsätze sicher, dass der für documentCache übrige Cache nicht sehr groß ist. Das heißt, halten Sie sie auf maximal 500 MB. Ein großer documentCache kann dazu führen, dass die Zeit für die Cache-Invalidierung verlängert wird.

  • Cache-Einstellungen in AEM 6.2 mit Oak 1.4.x:

    • In AEM 6.2 wurden Änderungen an der Funktionsweise dieser Cache-Einstellungen vorgenommen. In AEM 6.2 mit Oak 1.4 gibt es einen neuen Cache: prevDocCache. Sie können diesen Cache mit der Einstellung prevDocCachePercentage konfigurieren. Der Standardwert ist 4.
    • Der documentCache verwendet das verbleibende Cache-MB (Cache-Einstellung abzüglich der Größe aller anderen Caches): documentCache = cache - nodeCache - childrenCache - diffCache - docChildrenCache - prevDocCache

  • Implementieren der MongoDB-Produktions-Checkliste:
    https://docs.mongodb.org/manual/administration/production-checklist/ - Laut Mongo DB-Unterstützung haben viele der Elemente große Auswirkungen auf die Leistung. Wenden Sie sich bei Fragen direkt an den MongoDB-Support.

  • Leseleistung: Fügen Sie Ihren Mongo DB-URL auf jedem AEM Knoten diesen Abfragezeichenfolgenparameter hinzu: ?readPreference=secondaryPreferred
    Dieser Parameter weist das System an, Lesevorgänge aus der Sekundarstufe durchzuführen, was eine zusätzliche Leseleistung bietet.

  • Erhöhen Sie den Thread-Pool für Oak-Beobachtung: open /system/console/configMgr/org.apache.sling.commons.threads.impl.DefaultThreadPool.factory Setzen Sie den Namen auf Oak-Beobachtung und legen Sie die minimale und maximale Poolgröße auf 20 fest.

  • Erhöhen Sie die Länge der Beobachtungswarteschlange: Erstellen Sie eine Datei mit dem Namen com.adobe.granite.repository.impl.SlingRepositoryManager.cfg mit dem Parameter oak.observation.queue-length=50000. Platzieren Sie sie im Ordner /crx—quickstart/install .

  • Vermeiden Sie langwierige Abfragen: Legen Sie die Systemeigenschaft in den JVM-Parametern fest: -Doak.mongo.maxQueryTimeMS=60000 , um Abfragen zu vermeiden, die länger als 1 Minute dauern.
    ​12. Tar-Speicheroptimierung
    Microkernel rufen keine speicherzugeordneten Dateien direkt auf. JDK verwendet jedoch intern speicherzugeordnete Dateien für effizientes Lesen. Unter bestimmten Windows-64-Bit-Betriebssystemen können Dateien, die mit einem Speicher gemappt sind, möglicherweise nicht bereinigt werden und den gesamten nativen Betriebssystemspeicher verbrauchen. Installieren Sie die leistungsbezogenen Patches/Hotfixes von Microsoft (siehe KB 2731284) und Oracle.

Eine alternative Option besteht darin, den Speicherzuordnungsmodus zu deaktivieren, indem tarmk.mode=32 in SegmentNodeStoreService.config hinzugefügt wird, bis das Problem mit dem Betriebssystem behoben ist. Die Nachteile der Deaktivierung machen I/O-intensiv. Stellen Sie sicher, dass Sie die I/O-Seitensperre erhöhen.
​13. TarMK revision clean (compaction)
Ab AEM 6.3 ist die Online-Komprimierung (auch als Online-Revisionsbereinigung bezeichnet) standardmäßig aktiviert. Weitere Informationen finden Sie auf dieser Seite .
​14. Benutzer von Cloud Manager für Adobe Managed Services (AMS)
Mit Cloud Manager (nur AMS-Benutzer) können Sie eine erfolgreiche AEM Implementierung mit geführten Leistungstests und automatisierter Skalierung sicherstellen.

recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f