AEM 6.x | Tipps zur Leistungsoptimierung

Implementieren und führen Sie Auslastungstests durch, die realistische Szenarien sowohl in der Autoren- als auch in der Veröffentlichungsinstanz simulieren. Die Erforschung und Definition der zu erwartenden Belastung ist dabei ein entscheidender Schritt. In diesem Schritt können Sie nachweisen, ob die AEM-Anwendung, -Architektur und -AEM-Installation nach der Live-Schaltung in einer Produktionsumgebung ihre Aufgabe gut erfüllen.
Die Ergebnisse dieser Übung helfen festzustellen, ob eine Fehlkonfiguration, ein Anwendungsproblem, eine Dimensionierung, ein Hardwareproblem oder ein anderes Problem vorliegt, das die Systemleistung beeinträchtigt. Siehe auch die Leistungsrichtlinien und Überwachungsrichtlinien.

Zusätzlich zu Belastungstests können Sie mit Belastungstests die maximale Belastung definieren, die das System aushalten kann. Dieser Test kann Ihnen bei der Vorbereitung auf Traffic-Spitzen helfen. Weitere Informationen zu Leistungstests finden Sie hier.

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

Wenn Sie Windows Server verwenden, lesen Sie diesen Artikel.

Wenn Sie große Mengen an Assets (Bilder, Videos usw.) in AEM laden möchten, sollten Sie die Best Practices für Assets.

Bereitstellung von genügend RAM und Vermeidung von I/O-Überlastung
Wenn Sie die Produktion in jedem Maßstab ausführen möchten, sollte die Linux-Umgebung mit so viel RAM bereitgestellt werden, wie die Segment-TAR-Dateien zwischen den Offline-Komprimierungsspitzen (oder Online-Komprimierungsspitzen) anwachsen. Darüber hinaus wird durch Folgendes eine I/O-Sättigung vermieden.

• Separate Festplatten für Betriebssystem, Daten und Protokollierung
• Stellen Sie Daten-Disks mit Noatime bereit.
• Setzen Sie die Read-Ahead-Puffer auf der Daten-Disc auf 32.
• Idealerweise sollten Sie XFS über ext4 auf den Datenträgern verwenden.
• Wenn RedHat auf einer VM ausgeführt wird, stellen Sie sicher, dass der Entropie-Pool immer 1 K Bit > ist (verwenden Sie bei Bedarf rngtools)

Transparent Huge Pages unter Linux deaktivieren
AEM führt feinkörnige Lese-/Schreibvorgänge durch, während Linux Transparent Huge Pages für große Vorgänge optimiert ist. Daher wird empfohlen, Transparent Huge Pages bei Verwendung Mongo- oder TARSpeichers zu deaktivieren.

Aktivieren von Übergangs-Workflows
Ü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 einen Leistungsschub bewirken.
Dieser Anwendungsfall tritt in der Regel auf, wenn Assets in großen Mengen aufgenommen werden.
Befolgen Sie die Anweisungen unter Leistungsoptimierung von Assets.

Abstimmung der Sling-Auftragswarteschlangen
Das Massen-Hochladen großer Assets ist in der Regel ein sehr ressourcenintensiver Prozess. Standardmäßig entspricht die Anzahl der gleichzeitigen Threads pro Auftragswarteschlange der Anzahl der CPU-Kerne. Daher kann diese Werteinstellung eine Gesamtleistungsbeeinträchtigung und eine hohe Java-Heap-Nutzung verursachen.
Adobe empfiehlt, 50 % der CPU-Kerne nicht zu überschreiten. Um diesen Wert anzupassen, gehen Sie wie folgt vor: https:/host:port/system/console/configMgr/org.apache.sling.event.jobs.QueueConfiguration
Legen Sie queue.maxparallel auf einen Wert fest, der 50 % der CPU-Kerne des Servers darstellt, der Ihre AEM-Instanz hostet. Legen Sie beispielsweise für 8 CPU-Kerne den Wert auf 4 fest.

Optimieren 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 genannte Seite mit den empfohlenen Hotfixes.

Oak-Abfrage-Engine-/Indexoptimierungen

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

  • Informationen zum Analysieren langsamer Abfragen finden Sie in diesem Artikel.
  • Erstellen Sie die benutzerdefinierten Indizes unter dem Knoten oak:index für alle Sucheigenschaften, nach denen Sie suchen möchten, indem Sie diesem Artikel 🔗.
  • Versuchen Sie für jeden benutzerdefinierten Lucene-basierten Index, die Einstellung includedPaths (String) festzulegen, um den Index so einzuschränken, dass er nur auf bestimmte Inhaltspfade angewendet wird. Beschränken Sie dann die anwendbaren Suchvorgänge auf die Pfade, die im Index enthalten sind.

• JVM-Parameter
  Fügen Sie diese JVM-Parameter zum AEM-Startskript hinzu, um zu verhindern, dass die Systeme durch umfangreiche Abfragen überlastet werden. Beachten Sie, dass es sich hierbei um Standardwerte ab AEM 6.3 handelt.

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

  Die folgende Option kann ebenfalls 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.
  Außerdem werden ACLs nicht auf die Ergebnisse angewendet, sodass Knoten, die für die aktuelle Sitzung nicht sichtbar sind, weiterhin in die zurückgegebene Anzahl einbezogen werden. Daher kann die zurückgegebene Anzahl höher sein als die tatsächliche Anzahl von Ergebnissen, und die genaue Anzahl kann nur durch Iteration der Ergebnisse ermittelt werden:

  • Doak.fastQuerySize=true (siehe auch Ergebnisgröße in der Oak-Dokumentation)

  Achtung: Die Aktivierung fastQuerySize führt zu schnelleren Abfrageantworten. Bei einigen Abfragen gibt AEM jedoch eine ungenaue Ergebnisanzahl zurück. Wenn Sie in Ihrer Anwendung auf eine genaue Ergebnisanzahl angewiesen sind, verwenden Sie nicht fastQuerySize.

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

  • enable CopyOnRead (standardmäßig seit AEM 6.2 aktiviert)
  • enable CopyOnWrite (standardmäßig seit AEM 6.2 aktiviert)
  • Aktivieren Indexdateien vorholen (standardmäßig seit AEM 6.2 aktiviert)

  Weitere Informationen zu den verfügbaren Parametern 🔗 Sie unter https://jackrabbit.apache.org/oak/docs/query/lucene.html.
  Da einige Pfade nicht indiziert werden müssen, können Sie Folgendes tun:
  Wechseln Sie in CRXDE Lite zu /oak:index/lucene und legen Sie eine String-Eigenschaft mit mehreren Werten (Zeichenfolge) mit dem Namen excludedPaths mit den folgenden Werten fest: /var, /etc/workflow/instances, /etc/replication.

• Datenspeicher
  Wenn Sie AEM Assets verwenden oder über eine AEM-Anwendung verfügen, die Binärdateien häufig verwendet, empfiehlt Adobe die Verwendung eines externen Datenspeichers. Die Verwendung eines externen Datenspeichers trägt dazu bei, die maximale Leistung sicherzustellen. Siehe Dokumentation für detaillierte Anweisungen.
  Passen Sie bei Verwendung eines FileDataStore „cacheSizeInMB“ auf einen Prozentsatz Ihres verfügbaren Heaps an. Ein konservativer Wert beträgt 2 % des maximalen Heap. Beispiel für einen 8-GB-Heap:

  • maxCachedBinarySize=1048576
  • cacheSizeInMB=164

  Beachten Sie dass „maxCachedBinarySize auf 1 MB (1048576) festgelegt ist. Daher werden nur Dateien zwischengespeichert, die maximal 1 MB groß sind. Es kann auch sinnvoll sein, diese Einstellung auf einen kleineren Wert einzustellen.
  Bei einer großen Anzahl von Binärdateien sollten Sie die Leistung maximieren. Daher empfiehlt Adobe, anstelle der standardmäßigen Knotenspeicher einen externen Datenspeicher zu verwenden. Darüber hinaus empfiehlt Adobe die Anpassung der folgenden Parameter:

  • maxCachedBinarySize=10485760
  • cacheSizeInMB=4096

  Hinweis: Einstellung „cacheSizeInMB kann dazu führen, dass dem Java-Prozess der Speicher 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 anstelle von 164 festzulegen. Im Bereich von 2-10 % der maximalen Heap-Größe ist eine sichere Konfiguration. Adobe empfiehlt jedoch, Einstellungsänderungen mithilfe von Auslastungstests zu validieren und gleichzeitig die Speichernutzung zu überwachen.

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 kleine Blöcke aufteilt (Daten- oder Hash-Code oder indirekter Hash), sodass jeder Block in den Speicher passt. In 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. wenn der Lucene-Index groß ist), die Cache-Größ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“.
    Beispiel: blobCacheSize=1024
  • Siehe auch AEM-MongoDB Checkliste.

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

  • Sie können die Cachegröße (MB) über die Cacheeinstellung in DocumentNodeStoreService konfigurieren. Beispiel: cache=2048.

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

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

  • Mit der obigen Konfiguration beläuft sich der prozentuale Anteil auf insgesamt 95 %. Die restlichen 5 % des Cache werden an DocumentCache übergeben. documentCache = cache - nodeCache - childrenCache - diffCache - docChildrenCache

  • Achten Sie beim Verteilen der Cache-Prozentsätze darauf, dass der für DocumentCache verbleibende Cache nicht sehr groß ist. Das heißt, halten Sie die Größe auf maximal 500 MB fest. Ein großer DocumentCache kann zu einer Verlängerung der Zeit für die Cache-Invalidierung führen.

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

  • In AEM 6.2 wurde die Funktionsweise dieser Cache-Einstellungen geändert. 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 die 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 Elemente große Auswirkungen auf die Leistung. Wenden Sie sich bei Fragen direkt an den MongoDB-Support.

• Leseleistung Fügen Sie diesen Abfragezeichenfolgenparameter auf jedem AEM-Knoten zur Mongo-DB-URL hinzu: ?readPreference=secondaryPreferred
  Dieser Parameter weist das System an, Lesevorgänge vom sekundären Server auszuführen, wodurch eine zusätzliche Leseleistung erzielt wird.

• Threadpool für Oak-Observation erhöhen: /system/console/configMgr/org.apache.sling.commons.threads.impl.DefaultThreadPool.factory öffnen Legen Sie den Namen auf oak-observation und die Min.- und Max. Poolgröße auf 20 fest.

• Länge der Beobachtungswarteschlange erhöhen: 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.

• Langwierige Abfragen vermeiden: Legen Sie die Systemeigenschaft in den JVM-Parametern fest: -Doak.mongo.maxQueryTimeMS=60000, um zu vermeiden, dass Abfragen länger als 1 Minute ausgeführt werden.

Optimierung des TAR-Speichers
Mikrokernel rufen keine speicherzugeordneten Dateien direkt auf. JDK verwendet jedoch intern speicherzugeordnete Dateien, um effizientes Lesen zu ermöglichen. Unter bestimmten Windows 64-Bit-Betriebssystemen kann es vorkommen, dass die Dateien mit Speicherzuordnung nicht bereinigt werden und der gesamte native Betriebssystemspeicher verbraucht wird. Installieren Sie unbedingt 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 Betriebssystemproblem behoben ist. Der Nachteil der Deaktivierung ist eine hohe I/O-Intensität. Stellen Sie sicher, dass Sie die E/A-Seitensperre erhöhen.

TarMK-Revision bereinigen (Komprimierung)
Ab AEM 6.3 ist die Online-Komprimierung (auch als Online-Revisionsbereinigung bezeichnet) standardmäßig aktiviert. Weitere Informationen finden aufSeite .

Benutzende von Cloud Manager for Adobe Managed Services (AMS)
Mit Cloud Manager (nur AMS-Benutzer) können Sie mithilfe geführter Leistungstests und automatischer Skalierung eine erfolgreiche AEM-Bereitstellung sicherstellen.