Sie sehen sich Hilfeinhalte der folgenden Version an:

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:

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

AEM-

Produkt

Topologie

Betriebssystem

Anwendungsserver

JRE

Sicherheit

Mikrokernel

Datenspeicher

Indizierung

Webserver

Browser

Marketing Cloud

Sites

Keine HA

Windows

CQSE

Oracle

LDAP

Tar

Segment

Eigenschaft

Apache

Edge

Target

Assets

Veröffentlichen – HA

Solaris

WebLogic

IBM

SAML

MongoDB

Datei

Lucene

IIS

IE

Analytics

Communities

Autor – CS

Red Hat

WebSphere

HP

Oauth

RDB/Oracle

S3

Solr

iPlamet

Firefox

Campaign

Forms

Autor – Abladung

HP-UX

Tomcat 

 

 

RDB/DB2

MongoDB

 

 

Chrome

Social

Mobile

Autor – Cluster

IBM AIX

JBoss

 

 

RDB/MySQL

RDBMS

 

 

Safari

Audience

Multi-Site

ASRP

SUSE

 

 

 

RDB/SQL Server

 

 

 

 

Assets

Commerce

MSRP

Apple OS

 

 

 

 

 

 

 

 

Activation

Dynamic Media

JSRP

 

 

 

 

 

 

 

 

 

Mobile

Brand Portal

J2E

 

 

 

 

 

 

 

 

 

 

AoD

 

 

 

 

 

 

 

 

 

 

 

Livefyre

 

 

 

 

 

 

 

 

 

 

 

Screens

 

 

 

 

 

 

 

 

 

 

 

Document Security

 

 

 

 

 

 

 

 

 

 

 

Process Management

 

 

 

 

 

 

 

 

 

 

 

Desktop App

 

 

 

 

 

 

 

 

 

 

 

Hinweis:

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

Nutzung der Leistungsrichtlinien

Die Leistungsrichtlinien sollten in den folgenden Situationen Einsatz finden:

  • Erstbereitstellung: Wenn Sie zum ersten Mal die Bereitstellung von AEM Sites oder Assets planen, müssen Sie sich mit den verfügbaren Optionen zum Konfigurieren des Mikrokernels sowie des Knoten- und Datenspeichers vertraut machen (verglichen mit den Standardeinstellungen). Beispielsweise können die Standardeinstellungen des Datenspeichers für TarMK in einen Dateidatenspeicher geändert werden.
  • 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 bei einer Aktualisierung 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 wenn Sie TarMK anstatt MongoMK bereitstellen oder einen Dateidatenspeicher anstatt eines freigegebenen Amazon S3-Datenspeichers verwenden.
  • 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 beim Bereitstellen von MongoMK anstatt 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-Datenspeichers anstatt eines Dateidatenspeichers.

Einführung

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

Die AEM-Plattform besteht aus 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 die Zwischenspeicherung und URL-Filterung, das auf dem Webserver installiert ist. Weitere Informationen zur AEM-Architektur finden Sie unter Typische Bereitstellungsszenarien.

chlimage_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

Knotenspeicher

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.

Hinweis:

Adobe empfiehlt Kunden, TarMK als Standard-Persistenztechnologie für die Autoren- und die Veröffentlichungsinstanz von AEM zu verwenden.

Vorsicht:

Der RDB-Mikrokernel wird nur eingeschränkt unterstützt. Bevor Sie diesen Mikrokernel verwenden, kontaktieren Sie den Adobe-Kundendienst.

chlimage_1

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 Ihr Projekt beispielsweise eine große Anzahl von Medien-Assets benötigt, kann schneller darauf zugegriffen werden, wenn diese in einem Datei- oder S3-Datenspeicher gespeichert werden, anstatt direkt in einer MongoDB. 

Weitere Einzelheiten zu den verfügbaren Konfigurationsoptionen finden Sie unter Konfigurieren von Knotenspeichern und Datenspeichern.

chlimage_1

Suche

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. Solr sollte nur aus Gründen der Skalierbarkeit in speziellen und komplexen Bereitstellungen verwendet werden.

chlimage_1

Entwicklungsrichtlinien

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

  • Trennen Sie Darstellung, Logik und Inhalte
  • Nutzen Sie vorhandene AEM-APIs (z. B.: Sling) und Tools (z. B.: Replikation)
  • Entwickeln Sie im Kontext tatsächlicher Inhalte
  • Entwickeln Sie für optimale Cachefähigkeit
  • Reduzieren Sie die Anzahl der Speichervorgänge auf ein Minimum (z. B. mithilfe von Übergangs-Workflows)
  • Stellen Sie sicher, dass alle HTTP-Endpunkte RESTful sind
  • Schränken Sie die JCR-Überwachung ein
  • Berücksichtigen Sie asynchrone Threads

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:
    • @Reference in einer DS-Komponente
    • @Inject in einem Sling-Modell
    • sling.getService() in einer Sightly Use Class
    • sling.getService() in JSP
    • einen ServiceTracker
    • direkten Zugriff auf die OSGi-Dienstregistrierung

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

Benchmark-Szenarien

Hinweis:

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 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/Nach Assets suchen/Asset herunterladen/Asset-Metadaten lesen/Asset-Metadaten aktualisieren/Asset hochladen/Workflow zum Hochladen von Assets ausführen
  • Ausführungsmodus: gleichzeitige Benutzer, eine Interaktion pro Benutzer

Szenario mit mehreren Produkten

AEM Sites und Assets:

  • Sites-Benutzerinteraktionen: Artikelseite lesen/Seite lesen/Absatz erstellen/Absatz bearbeiten/Inhaltsseite erstellen/Inhaltsseite aktivieren/Autorensuche
  • Assets-Benutzerinteraktionen: Assets durchsuchen/Nach Assets suchen/Asset herunterladen/Asset-Metadaten lesen/Asset-Metadaten aktualisieren/Asset hochladen/Workflow zum Hochladen von Assets ausführen
  • Ausführungsmodus: gleichzeitige Benutzer, gemischte Interaktion 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 Interaktion pro Benutzer

TarMK

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 Bereitstellungsszenarien und TAR-Speicher.

Mindestarchitektur für TarMK – Richtlinien

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 Verwendung von TarMK eine optimale Leistung zu erzielen, sollten Sie als Ausgangspunkt eine Architektur mit folgenden Komponenten nutzen:

  • Eine Autoreninstanz
  • Zwei Veröffentlichungsinstanzen
  • Zwei Dispatcher

Nachfolgend sind die Architekturrichtlinien für AEM Sites und AEM Assets beschrieben.

Hinweis:

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

Tar-Architekturrichtlinien für AEM Sites

chlimage_1

Tar-Architekturrichtlinien für AEM Assets

chlimage_1

TarMK-Einstellungen – Richtlinien

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.
Warteschlange für die Granite-Übergangs-Workflows 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 zum AEM-Startskript hinzu, um zu verhindern, dass umfangreiche Abfragen die Systeme überlasten.
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 Datenspeicher-Konfigurationen.
Arbeitsablauf für DAM-Update-Asset Übergangs-Workflow markiert Dieser Workflow verwaltet die Aktualisierung von Assets.
DAM-Metadaten-Writeback Übergangs-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.

Leistungsbenchmarktest für TarMK

Technische Spezifikationen

Die Benchmarktests wurden für die folgenden Spezifikationen durchgeführt:

  Autorknoten
Server Bare-Metal-Hardware (HP)
Betriebssystem RedHat Linux
CPU/Kerne Intel(R) Xeon(R) CPU E5-2407 mit 2,40 GHz, 8 Kerne 
RAM 32 GB
Festplatte Magnetplattenspeicher
Java Oracle JRE Version 8
JVM-Heap 16 GB
Produkt  AEM 6.2
Knotenspeicher TarMK
Datenspeicher Dateidatenspeicher 
Szenario Einzelprodukt: Assets/30 gleichzeitige Threads

Ergebnisse der Leistungsbenchmarktests

Hinweis:

Die unten angegebenen Zahlen wurden mit 1 als Basislinie normiert und sind nicht die tatsächlichen Durchsatzzahlen.

chlimage_1
chlimage_1

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. 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 Bereitstellungsszenarien und Mongo-Speicher.

Mindestarchitektur für MongoMK – Richtlinien

Um bei Verwendung von MongoMK eine optimale Leistung zu erzielen, sollten Sie als Ausgangspunkt eine Architektur mit folgenden Komponenten nutzen:

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

Hinweis:

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

chlimage_1

MongoMK-Einstellungen – Richtlinien

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.
Warteschlange für die Granite-Übergangs-Workflows 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 zum AEM-Startskript hinzu, um zu verhindern, dass umfangreiche Abfragen die Systeme überlasten.
Lucene-Indexkonfiguration

CopyOnRead

CopyOnWrite

Prefetch Index Files

Aktiviert

Aktiviert

Aktiviert

Weitere Einzelheiten 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 Datenspeicher-Konfigurationen.
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 eingestellt.

Hat Auswirkungen auf die Zeit, die es dauert, eine Invalidierung des Caches durchzuführen.

oak-observation

thread pool

length

Min. und Max. = 20

50000

 

Leistungsbenchmarktest für MongoMK

Technische Spezifikationen

Die Benchmarktests wurden für die folgenden Spezifikationen durchgeführt:

  Autorknoten/b> 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 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 Magnetplattenspeicher – >1000 IOPS Magnetplattenspeicher – >1000 IOPS
Java Oracle JRE Version 8 k A
JVM-Heap 16 GB k A
Produkt  AEM 6.2 MongoDB 3.2 WiredTiger
Knotenspeicher MongoMK k A
Datenspeicher Dateidatenspeicher  k A
Szenario Einzelprodukt: Assets/30 gleichzeitige Threads Einzelprodukt: Assets/30 gleichzeitige Threads

Ergebnisse der Leistungsbenchmarktests

Hinweis:

Die unten angegebenen Zahlen wurden mit 1 als Basislinie normiert und sind nicht die tatsächlichen Durchsatzzahlen.

chlimage_1
chlimage_1

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

MongoMK im Vergleich zu TarMK – Richtlinien

Vorteile von TarMK

  • Wurde speziell für Content-Management-Anwendungen entwickelt
  • Dateien sind immer konsistent und können mit einem beliebigen dateibasierten Sicherungstool gesichert werden
  • Stellt einen Failover-Mechanismus bereit – weitere Einzelheiten finden Sie unter Cold Standby
  • Bietet hohe Leistung und zuverlässige Datenspeicherung bei minimalem Betriebsaufwand
  • Niedrige 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

MongoMK im Vergleich zu TarMK – Benchmarktests

Hinweis:

Die unten angegebenen Zahlen wurden mit 1 als Basislinie normiert und sind keine tatsächlichen Durchsatzzahlen.

Szenario 1 – Technische Spezifikationen

  Autor-OAK-Knoten 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 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 Magnetplattenspeicher – >1000 IOPS Magnetplattenspeicher – >1000 IOPS  
Java Oracle JRE Version 8 N/A  
JVM-Heap 16 GB 16 GB k A  
Produkt  AEM 6.2 MongoDB 3.2 WiredTiger  
Knotenspeicher TarMK oder MongoMK k A  
Datenspeicher Dateidatenspeicher  k A  
Szenario


Einzelprodukt: Assets/30 gleichzeitige Threads pro Lauf

 

Szenario 1 – Ergebnisse der Benchmarktests

chlimage_1

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 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
k A
JVM-Heap 16 GB 30 GB 30 GB k A
Produkt  AEM 6.2 AEM 6.2
MongoDB 3.2 WiredTiger
Knotenspeicher TarMK  MongoMK
k A
Datenspeicher Dateidatenspeicher 
Dateidatenspeicher

k A
Szenario



Vertikales Nutzungsszenario: Media/2.000 gleichzeitige Threads

Szenario 2 – Ergebnisse der Benchmarktests

chlimage_1

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

chlimage_1

Zusammenfassung der Leistungsrichtlinien

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:
    • Mindesttopologie: eine Autoreninstanz, zwei Veröffentlichungsinstanzen, zwei Dispatcher
    • Wenn der Dateidatenspeicher freigegeben wird, muss die Binärdatei-lose Replikation aktiviert sein
  • MongoMK ist die empfohlene Architektur für die horizontale Skalierbarkeit der Autorenschicht:
    • Mindesttopologie: drei Autoreninstanzen, drei MongoDB-Instanzen, zwei Veröffentlichungsinstanzen, zwei Dispatcher
    • Wenn der Dateidatenspeicher freigegeben wird, muss die Binärdatei-lose Replikation aktiviert sein
  • Der Knotenspeicher sollte auf der lokalen Festplatte und nicht auf einem NAS (Network Attached Storage) gespeichert werden
  • Amazon S3 ist der empfohlene Datenspeicher für ein Gesamtvolumen von Assets, das über 5 TB liegt
    • Der Amazon S3-Datenspeicher wird von der Autoren- und Veröffentlichungsschicht gemeinsam verwendet
    • Die Binärdatei-lose Replikation muss aktiviert sein
    • Für die Bereinigung des Datenspeichers ist ein erster Lauf auf allen Autoren- und Veröffentlichungsknoten, gefolgt von einem zweiten Lauf auf den Autorenknoten erforderlich
  • Neben dem vorkonfigurierten Index sollte ein benutzerdefinierter Index erstellt werden, basierend auf den am häufigsten durchgeführten Suchen
    • 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 „Update-Asset“, Deaktivieren von nicht verwendeten Listenern usw.

Weitere Einzelheiten finden Sie auch auf der Seite Empfohlen Bereitstellungen.

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