Leistungsrichtlinien

VORSICHT

AEM 6.4 hat das Ende der erweiterten Unterstützung erreicht und diese Dokumentation wird nicht mehr aktualisiert. Weitere Informationen finden Sie in unserer technische Unterstützung. Unterstützte Versionen suchen here.

Diese Seite erhält allgemeine Richtlinien zur Optimierung der Leistung Ihrer AEM-Bereitstellung. Wenn Sie mit der AEM noch nicht vertraut sind, lesen Sie zunächst die Leistungsrichtlinien:

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

Marketing Cloud

Sites

Nicht-HA

Windows

CQSE

Oracle

LDAP

Tar

Segment

Eigenschaft

Apache

Edge

Ziel

Assets

Publish-HA

Solaris

WebLogic

IBM

SAML

MongoDB

File

Lucene

IIS

IE

Analyse

Communities

Author-CS

Red Hat

WebSphere

HP

Oauth

RDB/Oracle

S3/Azure

Solr

iPlanet

FireFox

Campaign

Formulare

author-offload

HP-UX

Tomcat

RDB/DB2

MongoDB

Chrome

Sozial

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

Sie sollten die Leistungsrichtlinien in den folgenden Situationen verwenden:

  • Erstmalige Bereitstellung: Bei der erstmaligen Bereitstellung von AEM Sites oder Assets ist es wichtig, die beim Konfigurieren des Mikrokernels, Knotenspeichers und Datenspeichers verfügbaren Optionen zu verstehen (im Vergleich zu den Standardeinstellungen). Ändern Sie beispielsweise die Standardeinstellungen des Datenspeichers für TarMK in den 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 ein 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 die Bereitstellung von TarMK anstelle von MongoMK oder die Verwendung eines Dateidatenspeichers anstelle eines Amazon S3- oder Microsoft Azure-Datenspeichers.
  • Hinzufügen weiterer Autorknoten: Wenn die empfohlene TarMK-Topologie die Leistungsanforderungen nicht erfüllt und durch Upsizing des Autorknotens die maximal verfügbare Kapazität erreicht wurde, müssen Sie wissen, welche Leistungsunterschiede im Vergleich zur Nutzung von MongoMK mit drei oder mehr Autorknoten bestehen. Beispielsweise die 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

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). Welcher Mikrokernel Ihre Anforderungen erfüllt, hängt vom Zweck Ihrer Instanz und dem Bereitstellungstyp ab. 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, während der Speicherort der Inhaltsknoten und -eigenschaften als Knotenspeicher.

HINWEIS

Adobe empfiehlt, TarMK als standardmäßige Persistenztechnologie zu verwenden, die von Kunden sowohl für die AEM-Autoren- als auch für die Veröffentlichungsinstanz verwendet wird.

VORSICHT

Der RDB-Mikrokernel wird nur eingeschränkt unterstützt. Kontakt Adobe-Kundenunterstützung bevor Sie diesen 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 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 Einzelheiten zu den verfügbaren Konfigurationsoptionen finden Sie unter Konfigurieren von Knotenspeichern und Datenspeichern.

HINWEIS

Adobe empfiehlt folgende Bereitstellungsoption: AEM auf Azure oder Amazon Web Services (AWS) mit Adobe Managed Services. Dadurch profitieren Kunden vom Zugang zu einem Experten-Team, das Erfahrung mit der Bereitstellung und dem Betrieb von AEM in diesen Cloud-Computing-Umgebungen hat. Weitere Informationen finden Sie in der zusätzlichen Dokumentation zu Adobe Managed Services.

Für Empfehlungen zur Bereitstellung von AEM auf Azure oder AWS außerhalb von Adobe Managed Services empfehlen wir dringend, direkt mit dem Cloud-Anbieter oder einem unserer Partner zusammenzuarbeiten, der die Bereitstellung von AEM in der von Ihnen ausgewählten Cloud-Umgebung unterstützt. Der ausgewählte Cloud-Anbieter oder -Partner ist für die Größenspezifikationen, das Design und die Implementierung der Architektur verantwortlich, die er unterstützt, um Ihre spezifischen Anforderungen an Leistung, Auslastung, Skalierbarkeit und Sicherheit zu erfüllen.

Weitere Informationen finden Sie auch auf der Seite mit den technischen 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. Sie sollten Solr nur für die Skalierbarkeit in spezialisierten und komplexen Bereitstellungen verwenden.

chlimage_1-4

Entwicklungsrichtlinien

Sie sollten sich für AEM entwickeln, die Leistung und Skalierbarkeit. Nachfolgend finden Sie eine Reihe von Best Practices, die Sie befolgen können:

DO

  • Trennen von Präsentation, Logik und Inhalt
  • Verwenden Sie bestehende AEM-APIs (z. B.: Sling und Werkzeuge (z. B.: Replikation)
  • Im Kontext des tatsächlichen Inhalts entwickeln
  • Entwickeln für optimale Zwischenspeicherbarkeit
  • Minimieren Sie die Anzahl der Speichervorgänge (z. B.: durch Verwendung von Übergangs-Workflows)
  • Stellen Sie sicher, dass alle HTTP-Endpunkte RESTful sind.
  • Schränken Sie den Umfang der JCR-Beobachtung ein
  • Achten Sie auf asynchrone Threads

NICHT

  • Verwenden Sie JCR-APIs nicht direkt, wenn Sie

  • Ändern Sie /libs nicht, sondern verwenden Sie Überlagerungen

  • Verwenden Sie keine Abfragen, wo immer möglich

  • Verwenden Sie keine Sling-Bindungen, um OSGi-Dienste in Java-Code zu erhalten, sondern verwenden Sie stattdessen:

    • @Reference in einer DS-Komponente
    • @Inject in einem Sling-Modell
    • sling.getService() in einer Sightly Use Class
    • sling.getService() in einer JSP
    • a ServiceTracker
    • direkter Zugriff auf die OSGi-Dienstregistrierung

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

Benchmarkszenarios

HINWEIS

Alle auf dieser Seite angezeigten Benchmarktests wurden in einer Laboreinstellung 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 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/Inhaltssuche aktivieren
  • 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:

  • Artikelseite lesen (27,4 %), Seite lesen (10,9 %), Sitzung erstellen (2,6 %), Inhaltsseite aktivieren (1,7 %), Inhaltsseite erstellen (0,4 %), Absatz erstellen (4,3 %), Absatz bearbeiten (0,9 %), Bildkomponente (0,9 %), Assets durchsuchen (20 %), Asset-Metadaten lesen (8,5 %), Asset herunterladen (4,2 %), Nach Asset suchen (0,2 %), Asset-Metadaten aktualisieren (2,4 %), Asset hochladen (1,2 %), Projekt durchsuchen (4,9 %), Projekt lesen (6,6 %), Asset zu Projekt hinzufügen (1,2 %), Site zu Projekt hinzufügen (1,2 %), Projekt erstellen (0,1 %), Autorensuche (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. Benchmarktests 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 Sites mit einem hohen Traffic-Volumen. Es handelt sich hierbei nicht um die Mindestanforderungen für die Ausführung von AEM.

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

  • Eine Autoreninstanz
  • Zwei Veröffentlichungsinstanzen
  • 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

TarMK-Einstellungsleitlinie

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

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.
Granite-Verlaufs-Workflow-Warteschlange 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 im AEM-Startskript hinzu, um zu verhindern, dass umfassende Abfragen die Systeme überlasten.
Lucene-Indexkonfiguration

CopyOnRead

CopyOnWrite

Prefetch Index Files

Aktiviert

Aktiviert

Aktiviert

Weitere Informationen zu den verfügbaren Parametern finden Sie unter diese Seite.
Datenspeicher = S3-Datenspeicher

maxCachedBinarySize

cacheSizeInMB

1048576 (1 MB) oder kleiner

2-10 % der maximalen Heap-Größe

Siehe auch Datenspeicherkonfigurationen.
Workflow "DAM-Update-Asset" Transient Workflow aktiviert Dieser Workflow verwaltet die Aktualisierung von Assets.
DAM-Metadaten-Writeback Transient Workflow aktiviert Dieser Workflow verwaltet XMP Zurückschreiben in die ursprüngliche Binärdatei und legt das Datum der letzten Änderung in JCR fest.

TarMK-Leistungsbenchmark

Technische Spezifikationen

Die Benchmarktests wurden nach folgenden Spezifikationen durchgeführt:

Autorenknoten
Server Hardware für Bare Metal (HP)
Betriebssystem RedHat 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

Ergebnisse für Leistungsbeschriftungen

HINWEIS

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

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. Das bedeutet, dass immer mindestens zwei aktive Autoreninstanzen ausgeführt werden und MongoDB als Persistenzspeichersystem verwendet wird. Die Notwendigkeit, mehr als eine Autoreninstanz 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 tragbar ist.

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

Richtlinien zur Mindestarchitektur von MongoMK

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

  • Drei Autoreninstanzen
  • Zwei Veröffentlichungsinstanzen
  • 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-Replikatsätze 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

MongoMK-Einstellungsrichtlinien

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

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 Auftragswarteschlange der Anzahl der CPU-Kerne.
Granite-Verlaufs-Workflow-Warteschlange 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 im AEM-Startskript hinzu, um zu verhindern, dass umfassende Abfragen die Systeme überlasten.
Lucene-Indexkonfiguration

CopyOnRead

CopyOnWrite

Prefetch Index Files

Aktiviert

Aktiviert

Aktiviert

Weitere Informationen zu verfügbaren Parametern finden Sie unter diese Seite.
Datenspeicher = S3-Datenspeicher

maxCachedBinarySize

cacheSizeInMB

1048576 (1 MB) oder kleiner

2-10 % der maximalen Heap-Größe

Siehe auch 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 & 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 RedHat Linux RedHat 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 Grundlinie normalisiert und sind nicht die tatsächlichen Durchsatzzahlen.

chlimage_1-10 chlimage_1-11

TarMK im Vergleich zu MongoMK

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. Die Notwendigkeit, mehr als eine Autoreninstanz 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 tragbar ist.

Weitere Informationen zu TarMK und MongoMK finden Sie unter Empfohlene Bereitstellungen.

Richtlinien für TarMK und MongoMk

Vorteile von TarMK

  • Für Content Management-Anwendungen konzipierte Ziele
  • 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 mit minimalem Betriebsaufwand
  • Geringere TCO (Total Cost of Ownership)

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

TarMK vs. MongoMK-Benchmarks

HINWEIS

Die folgenden Zahlen wurden auf 1 als Grundlinie normalisiert und sind keine tatsächlichen Durchsatzzahlen.

Szenario 1 Technische Spezifikationen

Autoren-OAK-Knoten MongoDB-Knoten
Server Hardware für Bare Metal (HP) Hardware für Bare Metal (HP)
Betriebssystem RedHat Linux RedHat 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

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 Autoren als eine TarMK-Instanz verarbeiten.

Autoren-TarMK-Knoten Autoren-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



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 ist die empfohlene Architektur für die meisten Kunden:

    • Mindesttopologie: eine Autoreninstanz, zwei Veröffentlichungsinstanzen, zwei Dispatcher
    • Die Binärdatei-lose Replikation ist aktiviert, wenn der Dateidatenspeicher freigegeben wird.
  • MongoMK mit Dateidatenspeicher ist die empfohlene Architektur für die horizontale Skalierbarkeit der Autorenstufe:

    • Mindesttopologie: drei Autoreninstanzen, drei MongoDB-Instanzen, zwei Veröffentlichungsinstanzen, zwei Dispatcher
    • Die Binärdatei-lose Replikation ist aktiviert, wenn der Dateidatenspeicher freigegeben wird.
  • Nodestore sollte auf der lokalen Festplatte gespeichert werden, nicht auf einem NAS (Network Attached Storage).

  • Wenn Amazon S3 verwendet wird:

    • Der Amazon S3-Datenspeicher wird zwischen der Autoren- und der Veröffentlichungsstufe freigegeben.
    • Die Binärdatei-lose Replikation muss aktiviert sein
    • Die Speicherbereinigung erfordert einen ersten Lauf auf allen Autoren- und Veröffentlichungsknoten und einen zweiten Lauf auf auf der Autoreninstanz.
  • Zusätzlich zum vordefinierten Index sollte ein benutzerdefinierter Index erstellt werden basierend auf den häufigsten Suchvorgängen

    • Lucene-Indizes sollten für die benutzerdefinierten Indizes verwendet werden
  • Durch die Anpassung von Workflows kann die Leistung erheblich gesteigert werden, z. B. durch Entfernen des Videoschrittes im Workflow „Update-Asset“, Deaktivieren von nicht verwendeten Listenern usw.

Weitere Einzelheiten finden Sie auch auf der Seite Empfohlen Bereitstellungen.

Auf dieser Seite