Leistungsrichtlinien

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:

• AEM – Grundkonzepte
• Überblick über Speicher in AEM
• Empfohlene Bereitstellungen
• Technische Anforderungen

Nachfolgend sind die für AEM verfügbaren Bereitstellungsoptionen dargestellt (Bildlauf zur Ansicht aller Optionen):

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/Azure	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									Aktivierung
Dynamic Media	JSRP										Mobile
Brand Portal	J2E
AoD
Livefyre
Screens
Document Security
Process Management
Desktop-App

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- oder Microsoft Azure-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- oder Microsoft Azure-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:

For more information on the AEM platform, see What is 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. The third building block is the Dispatcher which is a module that handles caching and URL filtering and is installed on the webserver. Weitere Informationen zur AEM-Architektur finden Sie unter Typische Bereitstellungsszenarien.

Mikrokernels

Mikrokernels fungieren als Persistenzmanager in AEM. Es gibt drei Arten von Micro-Kerneln, die mit AEM verwendet werden: TarMK, MongoDB und Relational Database (unter eingeschränkter Unterstützung). Welcher Mikrokernel Ihre Anforderungen erfüllt, hängt vom Zweck Ihrer Instanz und dem Bereitstellungstyp ab. For additional information about Micro Kernels, see the Recommended Deployments page.

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.

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.

For further details on the available configuration options, see Configuring Node and Data Stores.

Suche

In diesem Abschnitt sind die in AEM verwendeten benutzerdefinierten Index-Provider aufgeführt. To know more about indexing, see Oak Queries and Indexing.

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

Die unten beschriebenen Testszenarien werden für die Abschnitte mit den Benchmarktests der Kapitel „TarMK“, „MongoMK“ und „TarMK im Vergleich zu MongoMK“ verwendet. To see which scenario was used for a particular benchmark test, read the Scenario field from the Technical Specifications table.

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.

For more information about TarMK, see Deployment Scenarios and Tar Storage.

Mindestarchitektur für TarMK – Richtlinien

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.

Tar-Architekturrichtlinien für AEM Sites

Tar-Architekturrichtlinien für AEM Assets

TarMK-Einstellungen – Richtlinien

Um eine optimale Leistung zu erzielen, sollten Sie die nachfolgenden Einstellungsrichtlinien befolgen. For instructions on how to change the settings, see this page.

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	Transient Workflow	markiert	Dieser Workflow verwaltet die Aktualisierung von Assets.
DAM-Metadaten-Writeback	Transient 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:

	Autorenknoten
Server	Bare Metal Hardware (HP)
Betriebssystem	RedHat Linux
CPU/Kerne	Intel® Xeon® CPU E5-2407 bei 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 parallele Threads

Ergebnisse der Leistungsbenchmarktests

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.

For more information about TarMK, see Deployment Scenarios and Mongo Storage.

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

MongoMK-Einstellungen – Richtlinien

Um eine optimale Leistung zu erzielen, sollten Sie die nachfolgenden Einstellungsrichtlinien befolgen. For instructions on how to change the settings, see this page.

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:

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

Ergebnisse der Leistungsbenchmarktests

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
• Provides a failover mechanism - see Cold Standby for more details
• 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

Szenario 1 – Technische Spezifikationen

	Autorenknoten	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 bei 2,40 GHz, 8 Kerne	Intel(R) Xeon(R) CPU E5-2407 bei 2,40 GHz, 8 Kerne
RAM	32 GB	32 GB
Festplatte	Magnetisch - > 1 k IOPS	Magnetisch - > 1 k 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 parallele Threads pro Ausführung

Szenario 1 – Ergebnisse der Benchmarktests

Szenario 2 – Technische Spezifikationen

	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-k-IOPS	SSD - 10-k-IOPS	SSD - 10-k-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: Media/2000 parallele Threads

Szenario 2 – Ergebnisse der Benchmarktests

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

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

• When using Amazon S3:

  • 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 Anpassen des Workflows kann die Leistung erheblich verbessert werden, z. B. durch Entfernen des Videoschritts im Arbeitsablauf "Asset aktualisieren", Deaktivieren von nicht verwendeten Listenern usw.

Weitere Einzelheiten finden Sie auch auf der Seite Empfohlen Bereitstellungen.