Leistungsrichtlinien performance-guidelines
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):
Verwendung der Leistungsrichtlinien when-to-use-the-performance-guidelines
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 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-Plattform the-aem-platform
Die AEM Plattform besteht aus den folgenden Komponenten:
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.
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). 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.
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 bezeichnet, während der Speicherort der Inhaltsknoten und -eigenschaften Knotenspeicher genannt wird.
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 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.
Weitere Informationen finden Sie auf der Seite technische 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.
Entwicklungsrichtlinien development-guidelines
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 benchmark-scenarios
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 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 tarmk-minimum-architecture-guidelines
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.
TAR-Architekturrichtlinien für AEM Sites
Tar-Architekturrichtlinien für AEM Assets
Richtlinie für TarMK-Einstellungen tarmk-settings-guideline
Um eine optimale Leistung zu erzielen, sollten Sie die nachfolgenden Einstellungsrichtlinien befolgen. Weitere Anweisungen zum Ändern der Einstellungen finden Sie unter Leistungsoptimierung.
TarMK-Leistungsbenchmark tarmk-performance-benchmark
Technische Spezifikationen technical-specifications
Die Benchmarktests wurden nach folgenden Spezifikationen durchgeführt:
Performance-Benchmark-Ergebnisse performance-benchmark-results
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. 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 mongomk-minimum-architecture-guidelines
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
Richtlinien für MongoMK-Einstellungen mongomk-settings-guidelines
Um eine optimale Leistung zu erzielen, sollten Sie die nachfolgenden Einstellungsrichtlinien befolgen. Weitere Anweisungen zum Ändern der Einstellungen finden Sie unter Leistungsoptimierung.
MongoMK-Performance-Benchmark mongomk-performance-benchmark
Technische Spezifikationen technical-specifications-1
Die Benchmarktests wurden nach folgenden Spezifikationen durchgeführt:
Performance-Benchmark-Ergebnisse performance-benchmark-results-1
TarMK im Vergleich zu MongoMK tarmk-vs-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 tarmk-vs-mongomk-guidelines
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 tarmk-vs-mongomk-benchmarks
Szenario 1 Technische Spezifikationen scenario-technical-specifications
Szenario 1 – Ergebnisse der Benchmarktests scenario-performance-benchmark-results
Szenario 2 Technische Spezifikationen scenario-technical-specifications-1
Szenario 2 – Ergebnisse der Benchmarktests scenario-performance-benchmark-results-1
Skalierbarkeitsrichtlinien für die Architektur für AEM Sites und Assets architecture-scalability-guidelines-for-aem-sites-and-assets
Zusammenfassung der Leistungsrichtlinien summary-of-performance-guidelines
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.