Leistungsrichtlinien performance-guidelines

CAUTION
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
NOTE
Die Leistungsrichtlinien gelten hauptsächlich für AEM Sites.

Verwendung der Leistungsrichtlinien when-to-use-the-performance-guidelines

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 introduction

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 the-aem-platform

Die AEM Plattform besteht aus den folgenden Komponenten:

chlimage_1

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

Die AEM Architektur the-aem-architecture

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 micro-kernels

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 nodestore

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.

NOTE
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.
CAUTION
Der RDB-Mikrokernel wird nur eingeschränkt unterstützt. Kontakt Adobe-Kundenunterstützung bevor Sie diesen Mikrokernel verwenden.

chlimage_1-3

Datenspeicher data-store

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.

NOTE
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 search-features

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

NOTE
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 development-guidelines

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 benchmark-scenarios

NOTE
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 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 tarmk-minimum-architecture-guidelines

NOTE
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.

NOTE
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 tarmk-settings-guideline

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 tarmk-performance-benchmark

Technische Spezifikationen technical-specifications

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 performance-bechmark-results

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

chlimage_1-7 chlimage_1-8

MongoMK 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 mongomk-minimum-architecture-guidelines

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
NOTE
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.
NOTE
Wenn der Dateidatenspeicher freigegeben wird, muss die Binärdatei-lose Replikation AKTIVIERT sein.

chlimage_1-9

MongoMK-Einstellungsrichtlinien mongomk-settings-guidelines

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 mongomk-performance-benchmark

Technische Spezifikationen technical-specifications-1

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 performance-benchmark-results

NOTE
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 tarmk-vs-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 tarmk-vs-mongomk-guidelines

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 tarmk-vs-mongomk-benchmarks

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

Szenario 1 Technische Spezifikationen scenario-technical-specifications

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 scenario-performance-benchmark-results

chlimage_1-12

Szenario 2 Technische Spezifikationen scenario-technical-specifications-1

NOTE
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 scenario-performance-benchmark-results-1

chlimage_1-13

Skalierbarkeitsrichtlinien für die Architektur für AEM Sites und Assets architecture-scalability-guidelines-for-aem-sites-and-assets

chlimage_1-14

Zusammenfassung der Leistungsrichtlinien summary-of-performance-guidelines

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.

recommendation-more-help
6a71a83d-c2e0-4ce7-a6aa-899aa3885b56