Diese Seite erhält allgemeine Richtlinien zur Optimierung der Leistung Ihrer AEM-Installation. Wenn Sie ein neuer AEM-Benutzer sind, gehen Sie die folgenden Seiten durch, bevor Sie diese Leistungsrichtlinien lesen:
Nachfolgend sind die verfügbaren Bereitstellungsoptionen für AEM dargestellt (Bildlauf zur Ansicht aller Optionen):
AEM Produkt |
Topologie |
Betriebssystem |
Anwendungsserver |
JRE |
Sicherheit |
Mikrokernel |
Datenspeicher |
Indizierung |
Webserver |
Browser |
Marketing Cloud |
Sites |
Keine HA |
Windows |
CQSE |
Oracle |
LDAP |
Tar |
Segment |
Property |
Apache |
Edge |
Target |
Assets |
Veröffentlichen – HA |
Solaris |
WebLogic |
IBM |
SAML |
MongoDB |
File |
Lucene |
IIS |
IE |
Analytics |
Communities |
Autor – CS |
Red Hat |
WebSphere |
HP |
Oauth |
RDB/Oracle |
S3/Azure |
Solr |
iPlamet |
Firefox |
Campaign |
Formulare |
Autor – Abladung |
HP-UX |
Tomcat |
|
|
RDB/DB2 |
MongoDB |
|
|
Chrome |
Social |
Mobilgerät |
Autor – Cluster |
IBM AIX |
JBoss |
|
|
RDB/MySQL |
RDBMS |
|
|
Safari |
Audience |
Multi-Site |
ASRP |
SUSE |
|
|
|
RDB/SQL Server |
|
|
|
|
Assets |
Commerce |
MSRP |
Apple OS |
|
|
|
|
|
|
|
|
Aktivierung |
Dynamic Media |
JSRP |
|
|
|
|
|
|
|
|
|
Mobilgerät |
Brand Portal |
J2E |
|
|
|
|
|
|
|
|
|
|
AoD |
|
|
|
|
|
|
|
|
|
|
|
Livefyre |
|
|
|
|
|
|
|
|
|
|
|
Screens |
|
|
|
|
|
|
|
|
|
|
|
Document Security |
|
|
|
|
|
|
|
|
|
|
|
Process Management |
|
|
|
|
|
|
|
|
|
|
|
-Desktop-Programm |
|
|
|
|
|
|
|
|
|
|
|
Die Leistungsrichtlinien gelten hauptsächlich für AEM Sites.
Die Leistungsrichtlinien sollten in den folgenden Situationen Einsatz finden:
Dieses Kapitel gibt einen allgemeinen Überblick über die AEM-Architektur und ihre wichtigsten Komponenten. Darüber hinaus werden Entwicklungsrichtlinien bereitgestellt und Testszenarien beschrieben, die für die TarMK- und MongoMK-Benchmarktests genutzt wurden.
Die AEM-Plattform besteht aus folgenden Komponenten:
Weitere Informationen zur AEM finden Sie unter Was ist AEM?
Eine AEM-Bereitstellung umfasst drei wichtige Bausteine. Die Autoreninstanz, die von Inhaltsautoren, Redakteuren und Genehmigungsberechtigten zum Erstellen und Überprüfen von Inhalten verwendet wird. Wenn Inhalte genehmigt werden, werden sie auf einem zweiten Instanztyp, der Veröffentlichungsinstanz veröffentlicht, über die Endbenutzer auf die Inhalte zugreifen können. Der dritte Baustein ist der Dispatcher, ein Modul, das die Zwischenspeicherung und URL-Filterung verarbeitet und auf dem Webserver installiert ist. Weitere Informationen zur AEM-Architektur finden Sie unter Typische Bereitstellungsszenarien.
Mikrokernels fungieren als Persistenzmanager in AEM. Es gibt drei Arten von Micro-Kerneln, die mit AEM verwendet werden: TarMK, MongoDB und Relational Database (unter eingeschränkter Unterstützung). Welcher Mikrokernel Ihre Anforderungen erfüllt, hängt vom Zweck Ihrer Instanz und dem Bereitstellungstyp ab. Weitere Informationen zu Micro-Kerneln finden Sie auf der Seite Empfohlene Bereitstellungen.
In AEM können Binärdaten unabhängig von Inhaltsknoten gespeichert werden. Der Speicherort, an dem Binärdaten gespeichert werden, wird als Datenspeicher bezeichnet, während der Speicherort für die Inhaltsknoten und Eigenschaften der Knotenspeicher ist.
Adobe empfiehlt Kunden, TarMK als Standard-Persistenztechnologie für die Autoren- und die Veröffentlichungsinstanz von AEM zu verwenden.
Der RDB-Mikrokernel wird nur eingeschränkt unterstützt. Bevor Sie diesen Mikrokernel verwenden, kontaktieren Sie den Adobe-Kundendienst.
Muss eine große Anzahl von Binärdateien verarbeitet werden, wird empfohlen, statt der Standard-Knotenspeicher einen externen Datenspeicher zu verwenden, um die Leistung zu maximieren. Wenn für Ihr Projekt z. B. eine große Anzahl von Medien-Assets erforderlich ist, wird ein schnellerer Zugriff ermöglicht, wenn Sie die Assets im Datei- oder Azure-/S3-Datenspeicher und nicht direkt in einer MongoDB speichern.
Weitere Informationen zu den verfügbaren Konfigurationsoptionen finden Sie unter Konfigurieren von Knoten und Datenspeichern.
Adobe empfiehlt folgende Bereitstellungsoption: AEM auf Azure oder Amazon Web Services (AWS) mit Adobe Managed Services. Dadurch profitieren Kunden vom Zugang zu einem Expertenteam, das Erfahrung mit der Bereitstellung und dem Betrieb von AEM in diesen Cloud-Computing-Umgebungen hat. Bitte lesen Sie die zusätzliche Dokumentation zu Adobe Managed Services.
Für die Bereitstellung von AEM auf Azure oder AWS ohne Adobe Managed Services wird dringend empfohlen, direkt mit dem Cloud-Anbieter oder einem unserer Partner, der die Bereitstellung von AEM in der gewünschten Cloud-Umgebung unterstützt, zusammenzuarbeiten. Der ausgewählte Cloud-Anbieter oder Partner ist für die Größenspezifikation, das Design und die Implementierung der von ihm unterstützten Architektur verantwortlich, um Ihre spezifischen Anforderungen an Leistung, Last, Skalierbarkeit und Sicherheit zu erfüllen.
Weitere Informationen finden Sie auf der Seite Technische Anforderungen.
In diesem Abschnitt sind die in AEM verwendeten benutzerdefinierten Index-Provider aufgeführt. Weitere Informationen zur Indexierung finden Sie unter Oak-Abfragen und Indizierung.
Für den Großteil der Bereitstellungen empfiehlt Adobe den Lucene-Index. Solr sollte nur aus Gründen der Skalierbarkeit in speziellen und komplexen Bereitstellungen verwendet werden.
Bei der Entwicklung für AEM sollten Leistung und Skalierbarkeit im Mittelpunkt stehen. Nachfolgend finden Sie eine Reihe von Best Practices, die Sie befolgen können:
EMPFOHLEN
NICHT EMPFOHLEN
Verwenden Sie JCR-APIs nach Möglichkeit nicht direkt
Ändern Sie „/libs“ nicht, sondern verwenden Sie Überlagerungen
Verwenden Sie nach Möglichkeit keine Abfragen
Verwenden Sie keine Sling-Bindungen zum Abrufen von OSGi-Diensten in Java-Code; nutzen Sie stattdessen:
Weitere Einzelheiten zur Entwicklung in AEM finden Sie unter Entwicklung – Grundlagen. Weitere Best Practices finden Sie unter Best Practices für die Entwicklung.
Alle auf dieser Seite gezeigten Benchmarktests wurden in einer Lab-Umgebung durchgeführt.
Die unten beschriebenen Testszenarien werden für die Abschnitte mit den Benchmarktests der Kapitel „TarMK“, „MongoMK“ und „TarMK im Vergleich zu MongoMK“ verwendet. Um zu sehen, welches Szenario für einen bestimmten Benchmark-Test verwendet wurde, lesen Sie das Feld Szenario in der Tabelle Technische Spezifikationen.
Einzelprodukt-Szenario
AEM Assets:
Szenario mit mehreren Produkten
AEM Sites und Assets:
Vertikales Nutzungsszenario
Medien:
Dieses Kapitel enthält allgemeine Leistungsrichtlinien für TarMK sowie die Mindestanforderungen für die Architektur und die Konfigurationseinstellungen. Darüber hinaus werden Informationen zu Benchmarktests als zusätzliche Erläuterung bereitgestellt.
Adobe empfiehlt Kunden, TarMK als Standard-Persistenztechnologie in allen Bereitstellungsszenarien zu verwenden, sowohl für die Autoren- als auch die Veröffentlichungsinstanz von AEM.
Weitere Informationen zu TarMK finden Sie unter Bereitstellungsszenarios und Teer-Datenspeicherung.
Die unten angegebenen Richtlinien zur Mindestarchitektur gelten für Produktionsumgebungen und Sites mit einem hohen Traffic-Volumen. Dies sind not die Minimalspezifikationen, die zum Ausführen von AEM erforderlich sind.
Um bei Verwendung von TarMK eine optimale Leistung zu erzielen, sollten Sie als Ausgangspunkt eine Architektur mit folgenden Komponenten nutzen:
Nachfolgend sind die Architekturrichtlinien für AEM Sites und AEM Assets beschrieben.
Wenn der Dateidatenspeicher freigegeben wird, muss die Binärdatei-lose Replikation AKTIVIERT sein.
Tar-Architekturrichtlinien für AEM Sites
Tar-Architekturrichtlinien für AEM Assets
Um eine optimale Leistung zu erzielen, sollten Sie die nachfolgenden Einstellungsrichtlinien befolgen. Anweisungen zum Ändern der Einstellungen finden Sie auf dieser Seite unter .
Einstellung | Parameter | Wert | Beschreibung |
Sling-Auftragswarteschlangen | queue.maxparallel |
Setzen Sie den Wert auf die Hälfte der Anzahl der CPU-Kerne. | Standardmäßig entspricht die Anzahl der gleichzeitigen Threads pro Auftragswarteschlange der Anzahl der CPU-Kerne. |
Warteschlange für die Granite-Übergangs-Workflows | Max Parallel |
Setzen Sie den Wert auf die Hälfte der Anzahl der CPU-Kerne. | |
JVM-Parameter |
|
500000 100000 250000 True |
Fügen Sie diese JVM-Parameter zum AEM-Startskript hinzu, um zu verhindern, dass umfangreiche Abfragen die Systeme überlasten. |
Lucene-Indexkonfiguration |
|
Aktiviert Aktiviert Aktiviert |
Weitere Informationen zu den verfügbaren Parametern finden Sie auf dieser Seite. |
Datenspeicher = S3-Datenspeicher |
|
1048576 (1 MB) oder kleiner 2–10 % der maximalen Heap-Größe |
Weitere Informationen finden Sie unter Datenspeicher-Konfigurationen. |
Arbeitsablauf für DAM-Update-Asset | Transient Workflow |
markiert | Dieser Workflow verwaltet die Aktualisierung von Assets. |
DAM-Metadaten-Writeback | Transient Workflow |
markiert | Dieser Workflow verwaltet einen XMP-Writeback in die ursprünglichen Binärdaten und legt das Datum der letzten Änderung in der jcr fest. |
Die Benchmarktests wurden für die folgenden Spezifikationen durchgeführt:
Autorenknoten | |
---|---|
Server | Bare Metal Hardware (HP) |
Betriebssystem | RedHat Linux |
CPU/Kerne | Intel® Xeon® CPU E5-2407 bei 2,40 GHz, 8 Kerne |
RAM | 32 GB |
Festplatte | Magnetisch |
Java | Oracle JRE-Version 8 |
JVM-Heap | 16 GB |
Produkt | AEM 6.2 |
Knotenspeicher | TarMK |
Datenspeicher | Datei DS |
Szenario | Einzelprodukt: Assets/30 parallele Threads |
Die unten angegebenen Zahlen wurden mit 1 als Basislinie normiert und sind nicht die tatsächlichen Durchsatzzahlen.
Der Hauptgrund dafür, warum anstatt des TarMK der MongoMK als Persistenz-Backend ausgewählt werden sollte, liegt in der horizontalen Skalierung der Instanzen. Das bedeutet, dass immer mindestens zwei aktive Autoreninstanzen ausgeführt werden und MongoDB als Persistenzspeichersystem verwendet wird. Der Grund, warum mehr als eine Autoreninstanz ausgeführt werden muss, besteht im Allgemeinen darin, dass die CPU- und Speicherkapazität eines einzelnen Servers, der alle simultanen Bearbeitungsaktivitäten unterstützt, nicht mehr ausreichend ist.
Weitere Informationen zu TarMK finden Sie unter Bereitstellungsszenarios und Mongo-Datenspeicherung.
Um bei Verwendung von MongoMK eine optimale Leistung zu erzielen, sollten Sie als Ausgangspunkt eine Architektur mit folgenden Komponenten nutzen:
In Produktionsumgebungen wird MongoDB immer als Replikatgruppe mit einer primären und zwei sekundären Instanzen verwendet. Die Lese- und Schreibvorgänge gehen an die primäre Instanz und die Lesevorgänge können an die sekundären Instanzen gehen. Wenn kein Speicher verfügbar ist, kann eine der sekundären Instanzen durch einen Arbiter ersetzt werden. MongoDB-Replikatgruppen müssen jedoch immer aus einer ungeraden Anzahl von Instanzen bestehen.
Wenn der Dateidatenspeicher freigegeben wird, muss die Binärdatei-lose Replikation AKTIVIERT sein.
Um eine optimale Leistung zu erzielen, sollten Sie die nachfolgenden Einstellungsrichtlinien befolgen. Anweisungen zum Ändern der Einstellungen finden Sie auf dieser Seite unter .
Einstellung | Parameter | Wert (default) | Beschreibung |
Sling-Auftragswarteschlangen | queue.maxparallel |
Setzen Sie den Wert auf die Hälfte der Anzahl der CPU-Kerne. | Standardmäßig entspricht die Anzahl der gleichzeitigen Threads pro Auftragswarteschlange der Anzahl der CPU-Kerne. |
Warteschlange für die Granite-Übergangs-Workflows | Max Parallel |
Setzen Sie den Wert auf die Hälfte der Anzahl der CPU-Kerne. | |
JVM-Parameter |
|
500000 100000 250000 true 60000 |
Fügen Sie diese JVM-Parameter zum AEM-Startskript hinzu, um zu verhindern, dass umfangreiche Abfragen die Systeme überlasten. |
Lucene-Indexkonfiguration |
|
Aktiviert Aktiviert Aktiviert |
Weitere Einzelheiten zu verfügbaren Parametern finden Sie auf dieser Seite. |
Datenspeicher = S3-Datenspeicher |
|
1048576 (1 MB) oder kleiner 2–10 % der maximalen Heap-Größe |
Weitere Informationen finden Sie unter Datenspeicher-Konfigurationen. |
DocumentNodeStoreService |
|
2048 35 (25) 20 (10) 30 (5) 10 (3) 4 (4) ./cache,size=2048,binary=0,-compact,-compress |
Die Standardgröße des Caches ist auf 256 MB eingestellt. Hat Auswirkungen auf die Zeit, die es dauert, eine Invalidierung des Caches durchzuführen. |
oak-observation |
|
Min. und Max. = 20 50000 |
Die Benchmarktests wurden für die folgenden Spezifikationen durchgeführt:
Autorenknoten | MongoDB-Knoten | |
---|---|---|
Server | Bare Metal Hardware (HP) | Bare Metal Hardware (HP) |
Betriebssystem | RedHat Linux | RedHat Linux |
CPU/Kerne | Intel® Xeon® CPU E5-2407 bei 2,40 GHz, 8 Kerne | Intel® Xeon® CPU E5-2407 bei 2,40 GHz, 8 Kerne |
RAM | 32 GB | 32 GB |
Festplatte | Magnetisch - > 1 k IOPS | Magnetisch - > 1 k IOPS |
Java | Oracle JRE-Version 8 | Nicht zutreffend |
JVM-Heap | 16 GB | Nicht zutreffend |
Produkt | AEM 6.2 | MongoDB 3.2 WiredTiger |
Knotenspeicher | MongoMK | Nicht zutreffend |
Datenspeicher | Datei DS | Nicht zutreffend |
Szenario | Einzelprodukt: Assets/30 parallele Threads | Einzelprodukt: Assets/30 parallele Threads |
Die unten angegebenen Zahlen wurden mit 1 als Basislinie normiert und sind nicht die tatsächlichen Durchsatzzahlen.
Bei der Wahl zwischen den beiden Mikrokernels muss eine Grundregel berücksichtigt werden: TarMK ist für Leistung konzipiert, während MongoMK für Skalierbarkeit eingesetzt wird. Adobe empfiehlt Kunden, TarMK als Standard-Persistenztechnologie in allen Bereitstellungsszenarien zu verwenden, sowohl für die Autoren- als auch die Veröffentlichungsinstanz von AEM.
Der Hauptgrund dafür, warum anstatt des TarMK der MongoMK als Persistenz-Backend ausgewählt werden sollte, liegt in der horizontalen Skalierung der Instanzen. Das bedeutet, dass immer mindestens zwei aktive Autoreninstanzen ausgeführt werden und MongoDB als Persistenzspeichersystem verwendet wird. Der Grund, warum mehr als eine Autoreninstanz ausgeführt werden muss, besteht im Allgemeinen darin, dass die CPU- und Speicherkapazität eines einzelnen Servers, der alle simultanen Bearbeitungsaktivitäten unterstützt, nicht mehr ausreichend ist.
Weitere Einzelheiten zu den Unterschieden zwischen TarMK und MongoMK finden Sie unter Empfohlene Bereitstellungen.
Vorteile von TarMK
Kriterien für die Auswahl von MongoMK
Die unten angegebenen Zahlen wurden mit 1 als Basislinie normiert und sind keine tatsächlichen Durchsatzzahlen.
OAK-Autorenknoten | MongoDB-Knoten | ||
Server | Bare Metal Hardware (HP) | Bare Metal Hardware (HP) | |
Betriebssystem | RedHat Linux | RedHat Linux | |
CPU/Kerne | Intel(R) Xeon(R) CPU E5-2407 bei 2,40 GHz, 8 Kerne | Intel(R) Xeon(R) CPU E5-2407 bei 2,40 GHz, 8 Kerne | |
RAM | 32 GB | 32 GB | |
Festplatte | Magnetisch - > 1 k IOPS | Magnetisch - > 1 k IOPS | |
Java | Oracle JRE-Version 8 | Nicht zutreffend | |
JVM-Heap 16 GB | 16 GB | Nicht zutreffend | |
Produkt | AEM 6.2 | MongoDB 3.2 WiredTiger | |
Knotenspeicher | TarMK oder MongoMK | Nicht zutreffend | |
Datenspeicher | Datei DS | Nicht zutreffend | |
Szenario |
|
Um bei Verwendung von MongoDB dieselbe Anzahl von Autoreninstanzen wie bei einem TarMK-System nutzen zu können, benötigen Sie einen Cluster mit zwei AEM-Knoten. Ein MongoDB-Cluster mit vier Knoten kann die 1,8-fache Anzahl von Autoreninstanzen einer TarMK-Instanz verarbeiten. Ein MongoDB-Cluster mit acht Knoten kann die 2,3-fache Anzahl von Autoreninstanzen einer TarMK-Instanz verarbeiten.
Autor-TarMK-Knoten | Autor MongoMK-Knoten | MongoDB-Knoten | |
Server | AWS c3.8xlarge | AWS c3.8xlarge | AWS c3.8xlarge |
Betriebssystem | RedHat Linux | RedHat Linux | RedHat Linux |
CPU/Kerne | 32 | 32 | 32 |
RAM | 60 GB | 60 GB | 60 GB |
Festplatte | SSD - 10.000 IOPS | SSD - 10.000 IOPS | SSD - 10.000 IOPS |
Java | Oracle JRE-Version 8 | Oracle JRE-Version 8 |
Nicht zutreffend |
JVM-Heap 16 GB | 30 GB | 30 GB | Nicht zutreffend |
Produkt | AEM 6.2 | AEM 6.2 | MongoDB 3.2 WiredTiger |
Knotenspeicher | TarMK | MongoMK | Nicht zutreffend |
Datenspeicher | Datei DS | Datei DS |
Nicht zutreffend |
Szenario |
|
Die auf dieser Seite beschriebenen Richtlinien können wie folgt zusammengefasst werden:
TarMK mit Dateidatenspeicher ist die empfohlene Architektur für den Großteil der Kunden:
MongoMK ist die empfohlene Architektur für die horizontale Skalierbarkeit der Autorenschicht:
Der Knotenspeicher sollte auf der lokalen Festplatte und nicht auf einem NAS (Network Attached Storage) gespeichert werden
Bei Verwendung von Amazon S3:
Neben dem vorkonfigurierten Index sollte ein benutzerdefinierter Index erstellt werden, basierend auf den am häufigsten durchgeführten Suchen
Durch Anpassen des Workflows kann die Leistung erheblich verbessert werden, z. B. durch Entfernen des Videoschritts im Arbeitsablauf "Asset aktualisieren", Deaktivieren von nicht verwendeten Listenern usw.
Weitere Einzelheiten finden Sie auch auf der Seite Empfohlen Bereitstellungen.