Leistungsrichtlinien

Letzte Aktualisierung: 25. April 2025

Gilt für:
Experience Manager 6.5

Themen:
Konfiguration

Erstellt für:

Admin

Diese Seite erhält allgemeine Richtlinien zur Optimierung der Leistung Ihrer AEM-Bereitstellung. Wenn Sie neu bei AEM sind, sollten Sie die folgenden Seiten lesen, bevor Sie mit der Lektüre der Leistungsrichtlinien beginnen:

Nachstehend sind die verfügbaren Bereitstellungsoptionen für AEM dargestellt (führen Sie einen Bildlauf durch, um alle Optionen anzuzeigen):

AEM Produkt	Topologie	Betriebssystem	Anwendungs-Server	JRE	Sicherheit	Mikrokernel	Datenspeicher	Indizierung	Webserver	Browser	Experience Cloud
Sites	Nicht-HA	Windows	CQSE	Oracle	LDAP	TAR	Segment	Eigenschaft	Apache	Edge	Ziel
Assets	Veröffentlichungs-HA	Solaris™	WebLogic	IBM®	SAML	MongoDB	File	Lucene	IIS	IE	Analyse
Communities	Autoren-CS	Red Hat®	WebSphere®	HP	OAuth	RDB/Oracle	S3/Azure	Solr	iPlanet	Firefox	Campaign
Formulare	Author-Auslagerung	HP-UX	Tomcat			RDB/DB2	MongoDB			Chrome	Social
Mobilgerät	Author-Cluster	IBM® AIX®	JBoss®			RDB/MySQL	RDBMS			Safari	Zielgruppe
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

HINWEIS

Die Leistungsrichtlinien gelten hauptsächlich für AEM Sites.

Verwendung der Leistungsrichtlinien

Verwenden Sie die Leistungsrichtlinien in den folgenden Situationen:

Erstmalige Implementierung: Bei der erstmaligen Implementierung von AEM Sites oder Assets ist es wichtig, die zur Verfügung stehenden Optionen zu verstehen. Insbesondere bei der Konfiguration des Mikrokernels, Knotenspeichers und Datenspeichers (im Vergleich zu den Standardeinstellungen). Ändern Sie beispielsweise die Standardeinstellungen des Datenspeichers für TarMK zu Dateidatenspeicher.
Aktualisierung auf eine neue Version: Bei der Aktualisierung auf eine neue Version müssen Sie sich über die Leistungsunterschiede im Vergleich zur aktuellen Umgebung im Klaren sein. Beispielsweise beim Upgrade von AEM 6.1 auf 6.2 oder von AEM 6.0 CRX2 auf 6.2 OAK.
Langsame Reaktionszeit: Wenn die ausgewählte Knotenspeicher-Architektur Ihre Anforderungen nicht erfüllt, müssen Sie wissen, welche Leistungsunterschiede im Vergleich zu anderen Topologieoptionen bestehen. Beispielsweise bei der Bereitstellung von TarMK anstelle von MongoMK oder der Verwendung eines Dateidatenspeichers anstelle eines Amazon S3- oder Microsoft® Azure-Datenspeichers.
Hinzufügen weiterer Autoren: Wenn die empfohlene TarMK-Topologie die Leistungsanforderungen nicht erfüllt und der Author-Knoten auf die maximale verfügbare Kapazität aufgestockt wurde, sollten Sie die Leistungsunterschiede verstehen. Vergleichen Sie die Verwendung von MongoMK mit drei oder mehr Author-Knoten. Beispielsweise bei der Bereitstellung von MongoMK anstelle von TarMK.
Hinzufügen weiterer Inhalte: Wenn die empfohlene Datenspeicherarchitektur Ihre Anforderungen nicht erfüllt, müssen Sie wissen, welche Leistungsunterschiede im Vergleich zu anderen Datenspeicheroptionen bestehen. Beispielsweise bei Verwendung des Amazon S3- oder Microsoft® Azure-Datenspeichers anstatt eines Dateidatenspeichers.

Einführung

Dieses Kapitel gibt einen allgemeinen Überblick über die AEM-Architektur und ihre wichtigsten Komponenten. Es enthält auch Entwicklungsrichtlinien und beschreibt die Testszenarien, die in den TarMK- und MongoMK-Benchmark-Tests verwendet werden.

Die AEM-Plattform

Die AEM Plattform besteht aus den folgenden Komponenten:

chlimage_1

Weitere Informationen zur AEM-Plattform finden Sie unter Was ist AEM?.

Die AEM-Architektur

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. Dies ist ein Modul für das Caching und die URL-Filterung, das auf dem Webserver installiert ist. Weitere Informationen zur AEM-Architektur finden Sie unter Typische Bereitstellungsszenarien.

chlimage_1-1

Mikrokernels

Mikrokernels fungieren als Persistenzmanager in AEM. In AEM werden drei Arten von Mikrokernels verwendet: TarMK, MongoDB und relationale Datenbank (mit eingeschränkter Unterstützung). Die Auswahl einer geeigneten Komponente hängt vom Zweck Ihrer Instanz und der Art der Implementierung ab, die Sie in Betracht ziehen. Weitere Informationen zu Mikrokernels finden Sie auf der Seite Empfohlene Bereitstellungen.

chlimage_1-2

Knotenspeicher

In AEM können Binärdaten unabhängig von Inhaltsknoten gespeichert werden. Der Speicherort, an dem die Binärdaten gespeichert werden, wird als Datenspeicher bezeichnet, während der Speicherort der Inhaltsknoten und -eigenschaften Knotenspeicher genannt wird.

HINWEIS

Adobe empfiehlt Kunden und Kundinnen, TarMK als Standard-Persistenztechnologie sowohl für die Authoring- als auch die Publishing-Instanz von AEM zu verwenden.

VORSICHT

Der RDB-Mikrokernel wird nur eingeschränkt unterstützt. Wenden Sie sich an die Adobe-Kundenunterstützung, bevor Sie diese Art von Mikrokernel verwenden.

chlimage_1-3

Datenspeicher

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 optimieren. 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 Einzelheiten zu den verfügbaren Konfigurationsoptionen finden Sie unter Konfigurieren von Knotenspeichern und Datenspeichern.

HINWEIS

Adobe empfiehlt, die Option zur Bereitstellung von AEM auf Azure oder Amazon Web Services (AWS) unter Verwendung von Adobe Managed Services zu wählen. Kunden profitieren von einem Team, das über die Erfahrung und die Fähigkeiten verfügt, AEM in diesen Cloud-Computing-Umgebungen bereitzustellen und zu betreiben. Siehe die zusätzliche Dokumentation zu Adobe Managed Services.

Für die Bereitstellung von AEM auf Azure oder AWS außerhalb von Adobe Managed Services wird von Adobe dringend empfohlen, direkt mit dem Cloud-Anbieter zu arbeiten. Oder arbeiten Sie mit einem der Partner von Adobe zusammen, die bei der Implementierung von AEM in der gewünschten Cloud-Umgebung helfen. Der ausgewählte Cloud-Anbieter oder -Partner ist verantwortlich für die Skalierungsspezifikationen, das Design und die Implementierung der unterstützten Architektur, um Ihre spezifischen Anforderungen an Leistung, Last, Skalierbarkeit und Sicherheit zu erfüllen.

Weitere Informationen finden Sie auf der Seite technische Anforderungen.

Suchen

In diesem Abschnitt sind die in AEM verwendeten benutzerdefinierten Index-Provider aufgeführt. Weitere Informationen zur Indizierung finden Sie unter Oak-Abfragen und Indizierung.

HINWEIS

Für den Großteil der Bereitstellungen empfiehlt Adobe den Lucene-Index. Verwenden Sie Solr nur für die Skalierbarkeit in spezialisierten und komplexen Implementierungen.

chlimage_1-4

Entwicklungsrichtlinien

Wenn Sie etwas für AEM entwickeln, sollte das immer die Leistung und Skalierbarkeit im Auge behalten. Im Folgenden finden Sie Best Practices, die Sie befolgen können:

Dies sollten Sie tun:

Trennen von Präsentation, Logik und Inhalt
Verwenden bestehender AEM-APIs (z. B.: Sling) und Werkzeuge (z. B.: Replikation)
Entwickeln im Kontext des tatsächlichen Inhalts
Entwickeln für optimale Zwischenspeicherbarkeit
Minimieren der Anzahl der Speichervorgänge (z. B. durch Verwendung von Übergangs-Workflows)
Sicherstellen, dass alle HTTP-Endpunkte RESTful sind.
Den Umfang der JCR-Beobachtung einschränken
Auf asynchrone Threads achten

Dies sollten Sie nicht tun:

JCR-APIs nach Möglichkeit nicht direkt verwenden
Keine „/libs“ ändern, sondern stattdessen Überlagerungen verwenden
Nach Möglichkeit keine Abfragen verwenden
Keine Sling-Bindungen verwenden, um OSGi-Dienste in Java™-Code zu erhalten, sondern stattdessen Folgendes:
- @Reference in einer DS-Komponente
- @Inject in einem Sling-Modell
- sling.getService() in einer Sightly-Anwendungsklasse
- sling.getService() in einer JSP
- einen ServiceTracker
- direkten Zugriff auf die Registrierung des OSGi-Diensts

Weitere Informationen zur Entwicklung in AEM finden Sie unter Entwickeln – Grundlagen. Weitere Best Practices finden Sie unter Best Practices für die Entwicklung.

Benchmark-Szenarios

HINWEIS

Alle auf dieser Seite angezeigten Benchmark-Tests wurden in einer Laborumgebung durchgeführt.

Die unten beschriebenen Testszenarien werden für die Abschnitte mit den Benchmark-Tests in den Kapiteln „TarMK“, „MongoMK“ und „TarMK im Vergleich zu MongoMK“ verwendet. Um festzustellen, welches Szenario für einen bestimmten Benchmarktest verwendet wurde, sehen Sie im Feld „Szenario“ der Tabelle Technische Spezifikationen nach.

Einzelprodukt-Szenario

AEM Assets:

Benutzerinteraktionen: Assets durchsuchen / Assets suchen / Asset herunterladen / Asset-Metadaten lesen / Asset-Metadaten aktualisieren / Asset hochladen / Workflow zum Hochladen von Assets ausführen
Ausführungsmodus: gleichzeitige Benutzer, einzelne Interaktion pro Benutzer

Szenario mit gemischten Produkten

AEM Sites und Assets:

Sites-Benutzerinteraktionen: Artikelseite lesen / Seite lesen / Absatz erstellen / Absatz bearbeiten / Inhaltsseite erstellen / Inhaltsseite aktivieren / Autorensuche
Benutzerinteraktionen in Assets: Assets durchsuchen / Assets suchen / Asset herunterladen / Asset-Metadaten lesen / Asset-Metadaten aktualisieren / Asset hochladen / Workflow zum Hochladen von Assets ausführen
Ausführungsmodus: gleichzeitige Benutzer, gemischte Interaktionen pro Benutzer

Vertikales Nutzungsszenario

Medien:

Read Article Page (27.4%), Read Page (10.9%), Create Session (2.6%), Activate Content Page (1.7%), Create Content Page (0.4%), Create Paragraph (4.3%), Edit Paragraph (0.9%), Image Component (0.9%), Browse Assets (20%), Read Asset Metadata (8.5%), Download Asset (4.2%), Search Asset (0.2%), Update Asset Metadata (2.4%), Upload Asset (1.2%), Browse Project (4.9%), Read Project (6.6%), Project Add Asset (1.2%), Project Add Site (1.2%), Create Project (0.1%), Author Search (0.4%)
Ausführungsmodus: gleichzeitige Benutzer, gemischte Interaktionen pro Benutzer

TarMK

Dieses Kapitel enthält allgemeine Leistungsrichtlinien für TarMK sowie die Mindestanforderungen für die Architektur und die Konfigurationseinstellungen. Benchmark-Tests werden ebenfalls zur weiteren Klärung 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 Bereitstellungsszenarien und TAR-Speicher.

Richtlinien zur Mindestarchitektur von TarMK

HINWEIS

Die unten angegebenen Richtlinien zur Mindestarchitektur gelten für Produktionsumgebungen und Websites mit einem hohen Traffic-Volumen. Bei diesen Richtlinien handelt es sich nicht um die Mindestanforderungen für die Ausführung von AEM.

Sie sollten mit der folgenden Architektur beginnen, um bei der Verwendung von TarMK eine gute Leistung zu erzielen:

Eine Authoring-Instanz
Zwei Publishing-Instanzen
Zwei Dispatcher

Nachfolgend finden Sie die Architekturrichtlinien für AEM Sites und AEM Assets.

HINWEIS

Wenn der Dateidatenspeicher freigegeben wird, muss die Binärdatei-lose Replikation AKTIVIERT sein.

TAR-Architekturrichtlinien für AEM Sites

chlimage_1-5

Tar-Architekturrichtlinien für AEM Assets

chlimage_1-6

Richtlinie für TarMK-Einstellungen

Um eine optimale Leistung zu erzielen, sollten Sie die nachfolgenden Einstellungsrichtlinien befolgen. Weitere Anweisungen zum Ändern der Einstellungen finden Sie unter Leistungsoptimierung.

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 Vorgangswarteschlange der Anzahl der CPU-Kerne.
Warteschlange für Granite-Übergangs-Workflow	`Max Parallel`	Setzen Sie den Wert auf die Hälfte der Anzahl der CPU-Kerne.
JVM-Parameter	`Doak.queryLimitInMemory` `Doak.queryLimitReads` `Dupdate.limit` `Doak.fastQuerySize`	500000 100000 250000 True	Fügen Sie diese JVM-Parameter in das AEM-Startskript ein, um zu verhindern, dass die Systeme durch umfangreiche Abfragen überlastet werden.
Lucene-Indexkonfiguration	`CopyOnRead` `CopyOnWrite` `Prefetch Index Files`	Aktiviert Aktiviert Aktiviert	Weitere Informationen zu den verfügbaren Parametern finden Sie auf dieser Seite.
Datenspeicher = S3-Datenspeicher	`maxCachedBinarySize` `cacheSizeInMB`	1048576 (1 MB) oder kleiner 2–10 % der maximalen Heap-Größe	Weitere Informationen finden Sie unter Datenspeicherkonfigurationen.
Workflow „DAM-Update-Asset“	`Transient Workflow`	aktiviert	Dieser Workflow verwaltet die Aktualisierung von Assets.
DAM-Metadaten-Writeback	`Transient Workflow`	aktiviert	Dieser Workflow verwaltet einen XMP-Writeback in die ursprünglichen Binärdaten und legt das Datum der letzten Änderung in der JCR fest.

TarMK-Leistungsbenchmark

Technische Spezifikationen

Die Benchmarktests wurden nach folgenden Spezifikationen durchgeführt:

	Autorenknoten
Server	Hardware für Bare Metal (HP)
Betriebssystem	Red Hat® Linux®
CPU/Kerne	Intel® Xeon® CPU E5-2407 mit 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 gleichzeitige Threads

Performance-Benchmark-Ergebnisse

HINWEIS

Die folgenden Zahlen wurden auf 1 als Baseline normalisiert und sind nicht die tatsächlichen Durchsatzwerte.

chlimage_1-7 chlimage_1-8

MongoMK

Der Hauptgrund dafür, warum anstatt des TarMK der MongoMK als Persistenz-Backend ausgewählt werden sollte, liegt in der horizontalen Skalierung der Instanzen. Diese Fähigkeit führt dazu, dass immer mindestens zwei aktive Authoring-Instanzen ausgeführt werden und MongoDB als Persistenzspeichersystem verwendet wird. Die Notwendigkeit, mehr als eine Authoring-Instanz auszuführen, resultiert im Allgemeinen aus der Tatsache, dass die CPU- und Speicherkapazität eines einzelnen Servers, der alle gleichzeitigen Authoring-Aktivitäten unterstützt, nicht mehr ausreicht.

Weitere Informationen zu TarMK finden Sie unter Bereitstellungsszenarien und Mongo-Speicher.

Richtlinien zur Mindestarchitektur von MongoMK

Sie sollten mit der folgenden Architektur beginnen, um bei der Verwendung von MongoMK eine gute Leistung zu erzielen:

Drei Authoring-Instanzen
Zwei Publishing-Instanzen
Drei MongoDB-Instanzen
Zwei Dispatcher

HINWEIS

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 die Speicherung nicht 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.

HINWEIS

Wenn der Dateidatenspeicher freigegeben wird, muss die Binärdatei-lose Replikation AKTIVIERT sein.

chlimage_1-9

Richtlinien für MongoMK-Einstellungen

Um eine optimale Leistung zu erzielen, sollten Sie die nachfolgenden Einstellungsrichtlinien befolgen. Weitere Anweisungen zum Ändern der Einstellungen finden Sie unter Leistungsoptimierung.

Einstellung	Parameter	Wert (Standard)	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 Vorgangswarteschlange der Anzahl der CPU-Kerne.
Warteschlange für Granite-Übergangs-Workflow	`Max Parallel`	Setzen Sie den Wert auf die Hälfte der Anzahl der CPU-Kerne.
JVM-Parameter	`Doak.queryLimitInMemory` `Doak.queryLimitReads` `Dupdate.limit` `Doak.fastQuerySize` `Doak.mongo.maxQueryTimeMS`	500000 100000 250000 True 60000	Fügen Sie diese JVM-Parameter in das AEM-Startskript ein, um zu verhindern, dass die Systeme durch umfangreiche Abfragen überlastet werden.
Lucene-Indexkonfiguration	`CopyOnRead` `CopyOnWrite` `Prefetch Index Files`	Aktiviert Aktiviert Aktiviert	Weitere Informationen zu verfügbaren Parametern finden Sie auf dieser Seite.
Datenspeicher = S3-Datenspeicher	`maxCachedBinarySize` `cacheSizeInMB`	1048576 (1 MB) oder kleiner 2–10 % der maximalen Heap-Größe	Weitere Informationen finden Sie unter Datenspeicherkonfigurationen.
DocumentNodeStoreService	`cache` `nodeCachePercentage` `childrenCachePercentage` `diffCachePercentage` `docChildrenCachePercentage` `prevDocCachePercentage` `persistentCache`	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 festgelegt. Hat Auswirkungen auf die Zeit, die zum Ausführen der Cache-Invalidierung benötigt wird.
oak-observation	`thread pool` `length`	min und max = 20 50000

MongoMK-Performance-Benchmark

Technische Spezifikationen

Die Benchmarktests wurden nach folgenden Spezifikationen durchgeführt:

	Autorenknoten	MongoDB-Knoten
Server	Hardware für Bare Metal (HP)	Hardware für Bare Metal (HP)
Betriebssystem	Red Hat® Linux®	Red Hat® Linux®
CPU/Kerne	Intel® Xeon® CPU E5-2407 mit 2,40 GHz, 8 Kerne	Intel® Xeon® CPU E5-2407 mit 2,40 GHz, 8 Kerne
RAM	32 GB	32 GB
Festplatte	Magnetisch – >1k IOPS	Magnetisch – >1k 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 gleichzeitige Threads	Einzelprodukt: Assets / 30 gleichzeitige Threads

Performance-Benchmark-Ergebnisse

HINWEIS

Die folgenden Zahlen wurden auf 1 als Baseline normalisiert und sind nicht die tatsächlichen Durchsatzwerte.

chlimage_1-10 chlimage_1-11

TarMK im Vergleich zu MongoMK

Bei der Wahl zwischen den beiden Optionen 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. Diese Funktionalität bedeutet, dass immer zwei oder mehr aktive Authoring-Instanzen ausgeführt werden und MongoDB als Persistenzspeichersystem verwendet wird. Die Notwendigkeit, mehr als eine Authoring-Instanz auszuführen, resultiert im Allgemeinen aus der Tatsache, dass die CPU- und Speicherkapazität eines einzelnen Servers, der alle gleichzeitigen Authoring-Aktivitäten unterstützt, nicht mehr ausreicht.

Weitere Einzelheiten zu TarMK und MongoMK finden Sie unter Empfohlene Implementierungen.

Richtlinien für den Vergleich von TarMK und MongoMK

Vorteile von TarMK

Speziell für Content-Management-Anwendungen entwickelt
Dateien sind immer konsistent und können mit jedem dateibasierten Backup-Tool gesichert werden
Stellt einen Failover-Mechanismus bereit – weitere Einzelheiten finden Sie unter Cold Standby
Bietet eine hohe Leistung und zuverlässige Datenspeicherung bei minimalem Betriebsaufwand
Geringere TCO (Total Cost of Ownership, Gesamtbetriebskosten)

Kriterien für die Auswahl von MongoMK

Anzahl der benannten, verbundenen Benutzer an einem Tag: Tausende oder mehr
Anzahl der gleichzeitigen Benutzer: Hunderte oder mehr
Volumen der erfassten Assets pro Tag: Hunderttausende oder mehr
Volumen der Seitenbearbeitungen pro Tag: Hunderttausende oder mehr
Volumen der Suchvorgänge pro Tag: Zehntausende oder mehr

Benchmarks für den Vergleich zwischen TarMK und MongoMK

HINWEIS

Die folgenden Zahlen wurden auf 1 als Basiswert normiert und sind keine tatsächlichen Durchsatzwerte.

Szenario 1 Technische Spezifikationen

	Autoren-OAK-Knoten	MongoDB-Knoten
Server	Hardware für Bare Metal (HP)	Hardware für Bare Metal (HP)
Betriebssystem	Red Hat® Linux®	Red Hat® Linux®
CPU/Kerne	Intel(R) Xeon(R) CPU E5-2407 mit 2,40 GHz, 8 Kerne	Intel(R) Xeon(R) CPU E5-2407 mit 2,40 GHz, 8 Kerne
RAM	32 GB	32 GB
Festplatte	Magnetisch – >1k IOPS	Magnetisch – >1k 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	Einzelprodukt: Assets / 30 gleichzeitige Threads pro Ausführung

Szenario 1 – Ergebnisse der Benchmarktests

chlimage_1-12

Szenario 2 Technische Spezifikationen

HINWEIS

Sie benötigen einen Cluster mit zwei AEM-Knoten, um bei Verwendung von MongoDB dieselbe Anzahl von Authoring-Instanzen wie bei einem TarMK-System nutzen zu können. 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 Authoring-Instanzen einer TarMK-Instanz verarbeiten.

	Autoren-TarMK-Knoten	Autoren-MongoMK-Knoten	MongoDB-Knoten
Server	AWS c3.8xlarge	AWS c3.8xlarge	AWS c3.8xlarge
Betriebssystem	Red Hat® Linux®	Red Hat® Linux®	Red Hat® 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	Vertikaler Anwendungsfall: Medien / 2000 gleichzeitige Threads

Szenario 2 – Ergebnisse der Benchmarktests

chlimage_1-13

Skalierbarkeitsrichtlinien für die Architektur für AEM Sites und Assets

chlimage_1-14

Zusammenfassung der Leistungsrichtlinien

Die auf dieser Seite vorgestellten Richtlinien lassen sich wie folgt zusammenfassen:

TarMK mit Dateidatenspeicher: Die empfohlene Architektur für die meisten Kundinnen und Kunden:
- Mindesttopologie: eine Authoring-Instanz, zwei Publishing-Instanz, zwei Dispatcher
- Wenn der Dateidatenspeicher freigegeben wird, muss die Binärdatei-lose Replikation aktiviert sein
MongoMK mit Dateidatenspeicher: Die empfohlene Architektur für die horizontale Skalierbarkeit der Authoring-Ebene:
- Mindesttopologie: drei Authoring-Instanzen, drei MongoDB-Instanzen, zwei Publishing-Instanzen, zwei Dispatcher
- Wenn der Dateidatenspeicher freigegeben wird, muss die Binärdatei-lose Replikation aktiviert sein
Knotenspeicher: Auf der lokalen Festplatte gespeichert, kein netzwerkgebundener Speicher (NAS)
Wenn Amazon S3 verwendet wird:
- Der Amazon S3-Datenspeicher wird von der Autoren- und der Publishing-Ebene gemeinsam genutzt.
- Die Binärdatei-lose Replikation muss aktiviert sein
- Die automatische Speicherbereinigung erfordert eine erste Ausführung auf allen Author- und Publish-Knoten und eine zweite Ausführung auf der Authoring-Instanz.
Zusätzlich zum vorkonfigurierten Index sollte ein benutzerdefinierter Index erstellt werden: Basierend auf den häufigsten Suchvorgängen
- Für die benutzerdefinierten Indizes sollten Lucene-Indizes verwendet werden
Durch die Anpassung von Workflows kann die Leistung erheblich gesteigert werden, z. B. durch Entfernen des Videoschrittes im Workflow „Asset aktualisieren“, Deaktivieren von nicht verwendeten Listenern usw.

Weitere Einzelheiten finden Sie auch auf der Seite Empfohlene Bereitstellungen.

recommendation-more-help