Hinweis:

Sie lesen die Adobe Experience Manager 6.x-Version der Tipps zur Leistungsoptimierung. Dieser Artikel ist auch für Version 5.x verfügbar.

Die Antwortzeit für Bearbeitung und Besucheranfragen ist langsam

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

Ursache

Die folgenden Faktoren beeinflussen Leistungsprobleme in AEM:

  • Ungenaues Design
  • Anwendungscode
  • Ungültige Datenträger-E/A-Konfiguration
  • Dimensionierung des Speicherplatzes
  • Netzwerkbandbreite und Latenz
  • AEM, das auf einigen vereinzelten Windows 2008- und Windows 2012-Versionen installiert wurde, bei denen die Speicherverwaltung ein Problem darstellt
  • Das Ändern von standardmäßigen Konfigurationen, wie unten beschrieben, kann die Leistung in AEM verbessern.

Leistungsprobleme verhindern

Im Folgenden sind einige Schritte aufgeführt, die Sie ergreifen können, um sicherzustellen, dass Sie Leistungsprobleme finden und beheben, bevor sie sich auf Ihre Benutzer auswirken:

  1. Implementieren und führen Sie Auslastungstests aus, die realistische Szenarien in Autoren- und Veröffentlichungsinstanzen simulieren. Das Erforschen und Definieren der zu erwartenden Belastung ist ein wichtiger Schritt in diesem Prozess. Mit diesem Schritt können Sie veranschaulichen, ob die AEM-Anwendung, Architektur und AEM-Installation gut ausgeführt werden können, sobald sie sich in einer Produktionsumgebung befinden. Die Ergebnisse dieser Übung helfen dabei, zu bestimmen, ob eine Fehlkonfiguration, ein Anwendungsfehler, eine Größenänderung, ein Problem mit der Hardware oder ein anderes Problem mit der Systemleistung vorliegt. Siehe auch Leistungsrichtlinien und Überwachungsrichtlinien

    1. Zusätzlich zum Testen der Leistung können Sie mit Hilfe von Belastungstests die maximale Leistung des Systems definieren. Dieser Test kann Ihnen bei der Vorbereitung auf Datenverkehrsspitzen helfen. Weitere Informationen zu Leistungstests finden Sie hier.
  2. Installieren Sie die empfohlenen AEM-Servicepakete, kumulative Fixpacks und Hotfixes:

    https://helpx.adobe.com/de/experience-manager/aem-releases-updates.html

  3. Wenn Sie Windows Server verwenden, dann lesen Sie diesen Artikel.

  4. Wenn Sie planen, große Mengen an Daten (Bilder, Videos, usw.) in AEM zu laden, stellen Sie sicher, dass Sie die Best Practices Assets anwenden.

  5. Stellen Sie genügend RAM bereit und vermeiden Sie IO-Sättigung.

    Wenn Sie beabsichtigen, die Produktion in einem beliebigen Maßstab zu betreiben, dann sollte die Linux-Umgebung mit so viel RAM ausgestattet sein, wie die TAR-Dateien zwischen Offline-Komprimierung (oder Online-Komprimierungsspitzen) wachsen.  Darüber hinaus vermeidet die folgende Methode die IO-Sättigung.

    • Getrennte OS/Daten/Logging-Disketten
    • Datenträger mit „noatime“ einbinden
    • Setzen Sie die Readahead-Buffer auf < 32 „auf der Datenplatte“.
    • Idealerweise verwenden Sie „xfs“ über „ext4“ auf den Datenfestplatten.
    • Wenn auf Red Hat in einer VM ausgeführt wird, stellen Sie sicher, dass der Entropie-Pool immer > 1K Bit ist (verwenden Sie rngtools)
  6. Deaktivieren Sie Transparent Huge Pages bei Linux

    AEM führt feinkörnige Lese- / Schreibvorgänge aus, während Linux Transparent Huge Pages für große Operationen optimiert ist. Daher wird empfohlen, Transparent Huge Pages zu deaktivieren, wenn Sie Mongo oder Tar-Speicher verwenden.

Hinweis:

Dieser Artikel bezieht sich auf AEM 6.x, für AEM / CQ 5.6.1 (oder frühere Versionen) Tipps zur Leistungsoptimierung, siehen Sie https://helpx.adobe.com/de/experience-manager/kb/performancetuningtips.html.

Transiente Workflows aktivieren

Um die hohen Aufnahmemengen zu optimieren, schlägt Adobe vor, den Workflow für das DAM-Update und den XMP-Metadaten-Writeback auf einen transienten Workflow umzustellen. Wie der Name andeutet, werden Laufzeitdaten, die sich auf die Zwischenarbeitsschritte in vorübergehenden Arbeitsabläufen beziehen, im JCR nicht gespeichert, wenn sie ausgeführt werden (die Ausgabewiedergaben werden natürlich beibehalten). Dies führt zu einer 10%igen Reduzierung in der Workflow-Verarbeitungszeit und reduziert das Repository-Wachstum erheblich. Es ist nicht erforderlich weitere CRUD-Workflows zu löschen. Darüber hinaus reduziert es die Anzahl der zu komprimierenden TAR-Dateien. Wenn Ihr Unternehmen das Beibehalten/Archivieren von Workflow-Laufzeitdaten für Audit-Zwecke vorschreibt, sollten Sie diese Funktion nicht aktivieren.

Hinweis:

Wenn Sie Übergangs-Workflows aktivieren möchten, beachten Sie Folgendes:

  • Übergangs-Workflows generieren keine Workflow-Ereignisse. Daher sollten Funktionen und Kunden, die von Ereignissen abhängig sind, keine Übergangs-Workflows aktivieren.
  • Übergangs-Workflows unterstützen keine Workflow-Abladung, welches von Workflow-Ereignissen abhängig ist.
  • Übergangs-Workflows unterstützen keine älteren CQ-Workflow-Ereignisse. Der Grund dafür ist, dass die Kompatibilitätsebene in CQEventDispatcher nicht funktioniert.
  • Übergangs-Workflows unterstützen keine Workflow-E-Mail-Benachrichtigungen. Der Grund dafür ist, dass der EmailNotificationService auf CQEventDispatcher basiert, der bei Übergangs-Workflows nicht funktioniert.
  • Übergangs-Workflows unterstützen keine Workflow-Statistiken. Der Grund dafür ist, dass der CQWorkflowStatisticsService auf CQEventDispatcher basiert, der mit Übergangs-Workflows nicht funktioniert.

In Fällen, in denen Sie keine Übergangs-Workflows verwenden können, müssen Sie regelmäßige Löschungen von Workflows durchführen, um archivierte DAM Update Asset-Workflows zu löschen. Hierdurch wird die Systemleistung aufrechterhalten. Um das Löschen von Workflows zu konfigurieren, fügen Sie über die OSGi-Konsole eine neue Adobe Granite Workflow Purge-Konfiguration hinzu. Konfigurieren Sie und legen Sie dies als Teil Ihres wöchentlichen Wartungsfensters fest.

Hinweis:

Durch Wechseln des DAM Update-Workflows auf einen temporären Workflow werden die Asset-Status-Aktualisierungen im Asset-Browser deaktiviert. Lesen Sie auch den Leitfaden zur Anpassung der Asset-Leistung.

  1. Gehen Sie in der zu konfigurierenden AEM-Instanz zu /miscadmin (z. B. http://<Server>:<Port>/miscadmin).

  2. Erweitern Sie in der Navigationsstruktur Tools > Workflow > Modelle > dam.

  3. Doppelklicken Sie auf DAM Update Asset.

  4. Wechseln Sie in der schwebenden Werkzeugpalette zur Registerkarte Seite und klicken Sie dann auf Seiteneigenschaften.

  5. Aktivieren Sie das Kontrollkästchen Transient Workflow, und klicken Sie auf OK.

Auftrag-Warteschlangen für die Tuning Sling

Bulk-Upload von großen Assets ist normalerweise ein sehr ressourcenintensiver Prozess. Standardmäßig entspricht die Anzahl der gleichzeitigen Threads pro Auftragwarteschlange der Anzahl der CPU-Kerne. Daher kann diese Werteinstellung zu einer allgemeinen Leistungsbeeinträchtigung und einem hohen Java-Heapverbrauch führen.

Adobe empfiehlt, dass Sie 50 % der CPU-Kerne nicht überschreiten. Um diesen Wert anzupassen, gehen Sie wie folgt vor:

http://<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, der Ihre AEM-Instanz hostet, darstellt. Stellen Sie beispielsweise für acht CPU-Kerne den Wert auf vier ein.

Feinabstimmung des Oak Repositorys

Stellen Sie zuerst 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-Abfragen und Indexoptimierung

  1. Installieren Sie die empfohlenen Indexe (nur für AEM 6.0).

    Mit den neuesten Verbesserungen in Oak und in QueryBuilder müssen Sie neue Oak-Indexe definieren, um sicherzustellen, dass Ihr System optimal läuft. Weitere Informationen über Oak-Indizierung finden Sie unter der Apache Jackrabbit Oak zugeordneten Seite.

    Nachfolgend sind einige Beispielpakete aufgeführt, die solch neue Indexdefinitionen enthalten. Es gibt auch ein zusammengefasstes AEM 6.0 Index-Definitionspaket (NPR-6340), das auf Anfrage beim AEM Kundendienst erhältlich ist.

    * damLuceneProperty.zip
    Empfohlene Indexdefinition für eine bessere Leistung der Suche bei klassischer Benutzeroberfläche von DAM (aktualisiert am 13.03.2015)

    * productsIndex.zip
    Empfohlene Indexdefinitionen zur besseren Suche nach Content Finder-Produkten

    Hinweis: Für AEM 6.1 sind die konsolidierten 6.0-Indexdefinitionen sofort verfügbar, mit Ausnahme vonrep:Token. Folgendes ist erforderlich:

    • Fügen Sie den Wert „rep:Token“ zur Eigenschaft „declaringNodeTypes“ des Knotens /oak:index/ hinzu.Knotentyp.
    • Setzen Sie für denselben Knoten den Wert der Eigenschaft „reindex“ auf wahr.
    • Klicken Sie auf Speichern, um neu zu indizieren.
  2. Erstellen Sie benutzerdefinierte Oak-Indizes für alle häufig verwendeten Suchanfragen.

    • Informationen zur Analyse langsamer Abfragen finden Sie in diesem Artikel.
    • Erstellen Sie die benutzerdefinierten Indizes unter demoak:index Folgen Sie diesem Artikel für alle Sucheigenschaften nach Knoten, nach denen Sie suchen möchten.
    • Versuchen Sie für jeden benutzerdefinierten Lucene-basierten Index, die includedPaths (String[])-Einstellungen so festzulegen, dass der Index eingeschränkt wird und nur auf bestimmten Inhaltspfaden angewendet wird. Beschränken Sie dann die anwendbaren Suchvorgänge auf die Pfade, die im Index enthalten sind.
  3. JVM-Parameter

    Fügen Sie diese JVM-Parameter im AEM-Startskript hinzu, um zu verhindern, dass umfangreiche Abfragen die Systeme überlasten.

    • -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 könnte auch die Leistung verbessern, aber sie verändert die Bedeutung des Aufrufs der Ergebnisgröße. Speziell werden nur Abfrageeinschränkungen berücksichtigt, die Teil des verwendeten Index sind, wenn die Größe berechnet wird. Außerdem werden ACLs nicht auf die Ergebnisse angewendet, daher werden Knoten, die für die aktuelle Sitzung nicht sichtbar sind, weiterhin in die zurückgegebene Zählung eingeschlossen. Die zurückgegebene Anzahl kann höher als die tatsächliche Anzahl von Ergebnissen sein. Die exakte Anzahl kann nur durch Iterieren durch die Ergebnisse bestimmt werden:

    • -Doak.fastQuerySize=true (weitere Informationen unter Ergebnisgröße in Oak-Dokumentation)
  4. Lucene-Indexkonfiguration

    Öffnen Sie /system/console/configMgr/org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProviderServiceand

    • Aktivieren Sie CopyOnRead (seit AEM 6.2 standardmäßig aktiviert)
    • Aktivieren Sie CopyOnWrite (seit AEM 6.2 standardmäßig aktiviert)
    • Aktivieren Sie Prefetch-Indexdateien (seit AEM 6.2 standardmäßig aktiviert)

    Weitere Informationen zu den verfügbaren Parametern finden Sie unter http://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. Legen Sie eine mehrwertige String-Eigenschaft (String[]) namens excludedPaths mit diesen Werten /var,/etc/workflow/instances,/etc/replication fest.

  5. Datenspeicher

    Wenn Sie AEM-Assets verwenden oder über eine AEM-Anwendung verfügen, die Binärdateien ausgiebig verwendet, empfiehlt Adobe die Verwendung eines externen GerätsDatenspeicher. Das Verwenden eines externalen Datenspeichers hilft, die maximale Leistung zu gewährleisten.  Siehe Dokumentationfür ausführliche Anweisungen

    Wenn Sie einen FileDataStore verwenden, optimieren Sie die cacheSizeInMB auf einen Prozentsatz Ihres verfügbaren Heaps. Ein konservativer Wert ist 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. Es werden also nur Dateien zwischengespeichert, die maximal 1 MB groß sind.  Es kann auch sinnvoll sein, diese Einstellung auf einen kleineren Wert einzustellen.

    Wenn Sie mit einer großen Anzahl von Binärdateien arbeiten, sollten Sie die Leistung optimieren. Adobe empfiehlt daher einen externenDatenspeicheranstelle des Standard-Knoten-Speichers zu verwenden. Zusätzlich empfiehlt Adobe das Anpassen der folgenden Parameter:

    • maxCachedBinarySize=10485760
    • cacheSizeInMB=4096

Hinweis:

Die Einstellung cacheSizeInMB kann dazu führen, dass dem Java-Prozess der Speicher ausgeht, wenn er zu hoch eingestellt ist. Wenn Sie beispielsweise die maximale Größe des Heap-Speichers auf 8 GB (-Xmx8g) festgelegt haben und erwarten, dass AEM und Ihre Anwendung einen kombinierten Heap von 4 GB verwenden, dann ist es sinnvoll, die cacheSizeInMB auf 82 anstatt 164 festzulegen. Eine sichere Konfiguration liegt im Bereich 2–10 % der maximalen Heap-Größe. Adobe empfiehlt jedoch, dass Sie die Einstellungsänderungen mit Auslastungstests überprüfen und gleichzeitig die Speichernutzung überwachen.

Optimierte Mongo-Speicherung

  1. MongoBlobStore Cache-Größe: DerBlobstorewird verwendet, um große binäre Objekte zu speichern und zu lesen. Intern ist der Store mit Cache implementiert, der dieBinärdaten inrelativ kleine Blöcke aufteilt (Daten oder Hash-Code oder indirekter Hash), so dass jeder Block in den Speicher passt.  In einem Standardsetup verwendet der MongoBlobStore eine festgelegte Zwischenspeichergröße von 16 MB.  Bei Bereitstellungen, in denen mehr RAM verfügbar ist und Blob Storage häufig aufgerufen wird (z. B. wenn der Lucene-Index groß ist), die Zwischenspeichergröße erhöhen. Diese Zwischenspeichergröße wird nur angewendet, wenn Sie MongoBlobStore (Standard) verwenden, nicht jedoch bei der Verwendung eines externenBlobstore.

    • Sie können die Zwischenspeichergröße (MB) mittels der blobCacheSize-Einstellung unter DocumentNodeStoreService konfigurieren.
      Beispiel:
        blobCacheSize=1024
  2. Dokumentenzwischenspeichergröße: Um die Leistung des Lesens von Knoten von MongoDB zu optimieren, müssen Sie die Zwischenspeichergröße von DocumentNodeStore anpassen.  Die Standardgröße des Caches ist auf 256 MB festgelegt, die auf verschiedene in „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. Zum Beispiel, cache=2048.
    • Setzen Sie alle folgenden Cache-Konfigurationen imcrx-quickstart/install/org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.configand fest und laden Sie dann den Test mit verschiedenen Werten, um zu sehen, welche für Ihre Umgebung die optimale Konfiguration ist. Beachten Sie, dass der verbleibende Cache-Prozentsatz dem Dokumentcache zugewiesen wird:
      • cache=2048
      • nodeCachePercentage=35
      • childrenCachePercentage=20
      • diffCachePercentage=30
      • docChildrenCachePercentage=10
    • Bei der obigen Konfiguration betragen die Prozentsätze 95 %.  Die restlichen 5 % des Zwischenspeichers werden an „documentCache“ übergeben.
        documentCache = cache -nodeCache- childrenCache - diffCache - docChildrenCache
    • Achten Sie bei der Verteilung der Cache-Prozentsätze darauf, dass der für den „documentCache“ verbleibende Cache nicht sehr groß ist. Das heißt, halten Sie es auf ~500 MB oder weniger. Ein großer „documentCache“ kann dazu führen, dass die Zeit für die Durchführung der Cache-Invalidierung verlängert wird.
  3. Cache-Einstellungen in AEM 6.2 mit Oak 1.4.x:

    • In AEM 6.2 wurden Änderungen an der Funktionsweise dieser Cacheeinstellungen 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.Standardist vier.
    • DiedocumentCache verwendet den verbleibenden Cache-MB (Cache-Einstellung abzüglich der Größe aller anderen Caches):
        documentCache = cache -nodeCache- childrenCache - diffCache - docChildrenCache - prevDocCache
  4. Zusammengesetzter Index (nur AEM 6.0 mit Oak 1.0.x und AEM 6.1 mit Oak 1.2.x)

    • Erstellen Sie im Hintergrund einen zusammengesetzten Index. Führen Sie diesen Vorgang wenn möglich nach Feierabend aus. Es ist am besten, AEM-Instanzen anzuhalten, während dies ausgeführt wird, damit es schneller abgeschlossen werden kann. Verwenden Sie den folgenden Befehl:
        nohup mongo localhost:27017/aem-author --eval "db.nodes.createIndex( {_modified:1, _id:1}, { background: true } )" &
    • Fügen Sie diesen JVM-Parameter zum Startskript von AEM hinzu:
        -Doak.mongo.disableIndexHint=true
  5. Implementieren Sie die Produktionsprüfliste von MongoDB
    http://docs.mongodb.org/manual/administration/production-checklist/ - entsprechend Mongo DB Support haben viele der Elemente dorteinegroße Auswirkung auf die Leistung. Wenden Sie sich bei Fragen direkt an den MongoDB.

  6. Leseperformance: Fügen Sie diesen Abfragezeichenfolgenparameter Ihrer Mongo DB-URL auf jedem AEM-Knoten hinzu:?readPreference=secondaryPreferred
    Dieser Parameter weist das System an, Lesevorgänge von der Sekundärseite durchzuführen, was zu einer zusätzlichen Leseleistung führt.

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

  8. 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- Länge = 50000. Legen Sie sie in dem Ordner /crx-­‐quickstart/install ab.

  9. Vermeiden Sie lange laufende Abfragen: Setzen Sie die Systemeigenschaft in den Parametern „JVM“: -Doak.mongo.maxQueryTimeMS = 60000, um Abfragen zu vermeiden, die länger als eine Minute dauern.

Teer-Lagerung

Mikro-Kernel rufen Memory-Mapped-Dateien nicht direkt auf. JDK verwendet jedoch intern Memory-Mapped-Dateien zum effizienten Lesen. Bei bestimmten Windows 64 Bit-Betriebssystemen kann es vorkommen, dass Dateien mit Speicherabbildungen nicht bereinigt werden und der gesamte native Arbeitsspeicher des Betriebssystems verbraucht wird. Stellen Sie sicher, dass Sie die leistungsabhängigen Patches/Hotfix vonmicrosoft(siehe KB 2731284) und Oracle installiert sind.

TarMK-Verdichtung.

Adobe empfiehlt, dass Sie für AEM 6.0, 6.1 und 6.2 die Offline-Verdichtung über das Oak-Run-Tool verwenden, das im Folgenden dokumentiert ist: http://docs.adobe.com/docs/en/aem/6-0/deploy/upgrade/microkernels-in-aem-6-0.html#Maintaining the Repository

Seit AEM 6.3 ist die Online-Verdichtung (auch als Online-Revisionsbereinigung bekannt) standardmäßig aktiviert. Gehen Sie zu dieser Seite für weitere Informationen.

Was jetzt?

Weitere Hilfe zu Ihren AEM-Leistungsproblemen:

  1. - Ihre AEM-Umgebung überwachen, um die möglichen Engpässe zu identifizieren.

    - Die allgemeinen kritischen AEM-Probleme und die zugehörigen Empfehlungen überprüfen

    - Die besten Vorgehensweisen zur Fehlerbehebung bei der Leistung wirksam einsetzen

  2. Der Diskussion in den Foren Tipps und Tricks zur Leistungsanpassung von AEM 6 beitreten

  3. Offizielle Unterstützung erhalten

    1. Die folgenden Daten sammeln:
      1. Prüfer-Ausgabe
      2. Sicherheitskopien
      3. Alle Protokolldateien
    2. Kontaktieren Sie die AEM-Kundenbetreuung

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