Ein Experience Manager Assets-Setup enthält eine Reihe von Hardware-, Software- und Netzwerkkomponenten. Je nach Ihrem Bereitstellungsszenario benötigen Sie möglicherweise bestimmte Konfigurationsänderungen an den Hardware-, Software- und Netzwerkkomponenten, um Leistungsengpässe zu vermeiden.
Darüber hinaus hilft die Identifizierung und Einhaltung bestimmter Richtlinien zur Hardware- und Softwareoptimierung beim Aufbau einer soliden Grundlage, die es Ihrer Experience Manager Assets-Implementierung ermöglicht, die Erwartungen hinsichtlich Leistung, Skalierbarkeit und Zuverlässigkeit zu erfüllen.
Eine ungenügende Leistung in Experience Manager Assets kann sich auf die Benutzererfahrung in Bezug auf interaktive Leistung, Asset-Verarbeitung, Downloadgeschwindigkeit und anderen Bereichen auswirken.
Daher gehört die Leistungsoptimierung zu den grundlegenden Aufgaben, bevor Sie Zielmetriken für Ihre Projekte erstellen.
In den folgenden Schlüsselbereichen sollten Sie besonders darauf achten, dass Leistungsprobleme erkannt und behoben werden, bevor sie sich auf das Benutzererlebnis auswirken.
Obwohl Experience Manager auf verschiedenen Plattformen unterstützt wird, hat Adobe die größte Unterstützung für native Tools unter Linux und Windows gefunden, was zu einer optimalen Performance und einfachen Implementierung beiträgt. Idealerweise sollten Sie ein 64-Bit-Betriebssystem bereitstellen, um die hohen Speicheranforderungen einer Experience Manager Assets-Bereitstellung zu erfüllen. Wie bei jeder Implementierung von Experience Managern sollten Sie TarMK so weit wie möglich implementieren. TarMK kann zwar nicht über eine einzelne Autoreninstanz skaliert werden, erzielt jedoch erfahrungsgemäß eine bessere Leistung als MongoMK. Sie können TarMK-Offload-Instanzen hinzufügen, um die Verarbeitungsleistung Ihrer Experience Manager Assets-Bereitstellung zu erhöhen.
Um die Upload-Zeit für Assets zu verbessern, verwenden Sie eine Hochleistungs-Datenspeicherung für den temporären Java-Ordner. Unter Linux und Windows können Sie beispielsweise ein RAM- oder SSD-Laufwerk verwenden. In Cloud-basierten Umgebungen kann ein äquivalenter Hochgeschwindigkeitsspeicher verwendet werden. In Amazon EC2 kann beispielsweise ein temporäres Laufwerk für den temporären Ordner verwendet werden.
Bei einer großen Speicherkapazität des Servers kann ein RAM-Laufwerk konfiguriert werden. Führen Sie unter Linux die folgenden Befehle aus, um ein RAM-Laufwerk von 8 GB zu erstellen:
mkfs -q /dev/ram1 800000
mkdir -p /mnt/aem-tmp
mount /dev/ram1 /mnt/aem-tmp
df -H | grep aem-tmp
Unter Windows OS verwenden Sie einen Treiber eines Drittanbieters, um ein RAM-Laufwerk zu erstellen, oder verwenden Sie einfach eine leistungsstarke Datenspeicherung wie SSD.
Sobald das temporäre Volume mit hoher Leistung fertig ist, stellen Sie den JVM-Parameter -Djava.io.tmpdir
ein. Sie könnten beispielsweise den JVM-Parameter unten zur Variablen CQ_JVM_OPTS
im Skript bin/start
von Experience Manager hinzufügen:
-Djava.io.tmpdir=/mnt/aem-tmp
Adobe empfiehlt die Bereitstellung von Experience Manager Assets unter Java 8, um eine optimale Leistung zu erzielen.
Legen Sie die folgenden JVM-Parameter fest:
-XX:+UseConcMarkSweepGC
-Doak.queryLimitInMemory
=500000-Doak.queryLimitReads
=100000-Dupdate.limit
=250000-Doak.fastQuerySize
=trueFür alle Experience Manager Assets-Benutzer wird empfohlen, den Datenspeicher vom Segmentspeicher zu trennen. Außerdem kann die Leistung durch die Konfiguration der Parameter maxCachedBinarySize
und cacheSizeInMB
maximiert werden. Stellen Sie maxCachedBinarySize
auf die kleinste im Cache unterstützte Dateigröße ein. Geben Sie die Größe des Arbeitsspeicher-Cache für den Datenspeicher in cacheSizeInMB
ein. Adobe empfiehlt, diesen Wert auf 2–10 Prozent der gesamten Heap-Größe einzustellen. Mithilfe von Last-/Leistungstests lässt sich die ideale Einstellung herausfinden.
Wenn Sie große Mengen von Assets auf Adobe Experience Manager hochladen, um unerwartete Spitzen beim Speicherverbrauch zu ermöglichen und um zu verhindern, dass JVM mit OutOfMemoryErrors fehlschlägt, reduzieren Sie die konfigurierte maximale Größe des gepufferten Bild-Cache. Betrachten wir ein Beispiel mit einem System, das über eine maximale Heap-Größe (-Xmx
param) von 5 GB verfügt und bei dem der Oak-Blob-Cache auf 1 GB und der Dokumenten-Cache auf 2 GB eingestellt ist. In diesem Fall würde der gepufferte Cache das Maximum von 1,25 GB Speicher in Anspruch nehmen, wodurch nur 0,75 GB Speicher für unerwartete Spitzen verblieben.
Konfigurieren Sie die Größe des gepufferten Cache in der OSGi-Webkonsole. Legen Sie bei https://host:port/system/console/configMgr/com.day.cq.dam.core.impl.cache.CQBufferedImageCache
die Eigenschaft cq.dam.image.cache.max.memory
in Byte fest. 1073741824 entspricht beispielsweise 1 GB (1024 x 1024 x 1024 = 1 GB).
Wenn Sie in Experience Manager 6.1 SP1 einen sling:osgiConfig
-Knoten zum Konfigurieren dieser Eigenschaft verwenden, stellen Sie sicher, dass der Datentyp auf "Lang"eingestellt ist. Weitere Details finden Sie unter CQBufferedImageCache belegt beim Asset-Upload den Heap.
Mit der Implementierung eines S3-Datenspeichers oder Shared File Datastore sparen Sie Speicherplatz auf der Festplatte und erhöhen den Netzwerkdurchsatz in großen Implementierungen. Weitere Informationen zu den Vor- und Nachteile der Verwendung eines gemeinsamen Datenspeichers finden Sie unter Handbuch zur Asset-Größenanpassung.
Mit der folgenden Konfiguration des S3-Datenspeichers (org.apache.jackrabbit.oak.plugins.blob.datastore.S3DataStore.cfg
) konnte Adobe binäre große Objekte (BLOBs) mit einer Größe von 12,8 TB von einem vorhandenen Dateidatenspeicher in einen S3-Datenspeicher am Standort eines Kunden extrahieren:
accessKey=<snip>
secretKey=<snip>
s3Bucket=<snip>
s3Region=us-standard
s3EndPoint=<a href="https://s3.amazonaws.com/">s3.amazonaws.com</a>
connectionTimeout=120000
socketTimeout=120000
maxConnections=80
writeThreads=60
concurrentUploadsThreads=30
asyncUploadLimit=30
maxErrorRetry=1000
path=/opt/author/crx-quickstart/repository/datastore
s3RenameKeys=false
s3Encryption=SSE_S3
proactiveCaching=true
uploadRetries=1000
migrateFailuresCount=400
Adobe empfiehlt die Aktivierung von HTTPS, da viele Unternehmen über Firewalls verfügen, die den HTTP-Verkehr überprüfen und sich dadurch negativ auf Uploads auswirken und Dateien beschädigen. Stellen Sie bei großen Datei-Uploads sicher, dass Benutzer über Kabelverbindungen zum Netzwerk verfügen, da ein WLAN-Netzwerk schnell überfordert ist. Richtlinien zum Identifizieren von Netzwerkengpässen finden Sie unter Handbuch zur Asset-Größenanpassung. Informationen zur Bewertung der Netzwerkleistung durch Analyse der Netzwerktopologie finden Sie unter Überlegungen zum Asset-Netzwerk.
Ihre Netzwerkoptimierungsstrategie hängt in erster Linie von der verfügbaren Bandbreite und der Belastung Ihrer Experience Manager-Instanz ab. Allgemeine Konfigurationsoptionen, einschließlich Firewalls oder Proxys, können zur Verbesserung der Netzwerkleistung beitragen. Die folgenden Aspekte sollten berücksichtigt werden:
Stellen Sie nach Möglichkeit den Workflow DAM Update Asset auf Transient ein. Die Einstellung trägt zu einer erheblichen Reduzierung des Overheads bei, der für die Verarbeitung der Workflows benötigt wird, da die Workflows in diesem Fall nicht die normalen Tracking- und Archivierungsprozesse durchlaufen.
Navigieren Sie zu /miscadmin
in der Experience Manager-Bereitstellung unter https://[aem_server]:[port]/miscadmin
.
Erweitern Sie Tools > Workflow > Modelle > dam.
Öffnen Sie DAM Update Asset. Wechseln Sie im unverankerten Tool-Fenster auf die Registerkarte Seite und klicken Sie auf Seiteneigenschaften.
Wählen Sie Übergangsarbeitsablauf und klicken Sie auf OK.
Einige Funktionen unterstützen keine Verlaufs-Workflows. Wenn für Ihre Assets-Bereitstellung diese Funktionen erforderlich sind, konfigurieren Sie keine vorübergehenden Workflows.
Wenn transiente Workflows nicht verwendet werden können, führen Sie das Workflow-Bereinigen regelmäßig aus, um archivierte DAM Update Asset zu löschen. Workflows stellen Sie sicher, dass die Systemleistung nicht beeinträchtigt wird.
Normalerweise führen Sie die Workflows wöchentlich aus. In ressourcenintensiven Szenarien, z. B. während der umfangreichen Asset-Erfassung, können Sie diese jedoch häufiger ausführen.
Um die Workflow-Bereinigung zu konfigurieren, fügen Sie in der OSGi-Konsole eine neue Adobe Granite-Workflow-Bereinigungskonfiguration hinzu. Konfigurieren und planen Sie im nächsten Schritt den Workflow als Teil des wöchentlichen Wartungsfensters.
Dauert die Bereinigung zu lange, kommt es zu einem Timeout. Daher sollten Sie sicherstellen, dass die Bereinigungsaufträge abgeschlossen sind. So vermeiden Sie, dass Bereinigungs-Workflows aufgrund der hohen Zahl an Workflows nicht abgeschlossen werden können.
Nach dem Ausführen zahlreicher nicht-transienter Workflows (die Workflow-Instanzknoten erstellen) können Sie beispielsweise ACS AEM Commons Workflow Remover auf Ad-hoc-Basis ausführen. Es entfernt redundante, abgeschlossene Workflow-Instanzen sofort, ohne dass Sie auf die Ausführung des Adobe Granite-Workflow-Bereinigungsplaners warten müssen.
Standardmäßig führt Experience Manager maximal parallele Aufträge aus, die der Anzahl der Prozessoren auf dem Server entsprechen. Das Problem bei dieser Einstellung besteht darin, dass während einer hohen Auslastung alle Prozessoren von DAM Update Asset Workflows belegt werden, was die Reaktionsgeschwindigkeit der Benutzeroberfläche verlangsamt und verhindert, dass Experience Manager andere Prozesse ausgeführt werden, die die Serverleistung und -stabilität sichern. Es hat sich bewährt, diese Einstellung so zu wählen, dass nur die Hälfte der auf dem Server verfügbaren Prozessoren verwendet wird:
Zugriff auf Experience Manager Autor https://[aem_server]:[port]/system/console/slingevent
.
Klicken Sie auf Bearbeiten in jeder Workflow-Warteschlange, die für Ihre Implementierung relevant ist, z. B. Granite Transient Workflow Queue.
Aktualisieren Sie den Wert von Maximale Anzahl paralleler Aufträge und klicken Sie auf Speichern.
Diese Einstellung des Werts auf die Hälfte der verfügbaren Prozesse ist für den Anfang eine praktikable Lösung. Unter Umständen müssen Sie diese Zahl jedoch nach oben oder unten anpassen, um den maximalen Durchsatz zu erreichen, und auch an die spezifische Umgebung anpassen. Es gibt separate Warteschlangen für Verlaufs- und Nicht-Verlaufs-Workflows sowie für andere Prozesse wie beispielsweise externe Workflows. Sind mehrere Warteschlangen, die auf 50 % der Prozessoren gesetzt sind, gleichzeitig aktiv, kann es schnell zu einer Überlastung des Systems kommen. Welche Warteschlangen stark ausgelastet sind, hängt in hohem Maße von den Benutzerimplementierungen ab. Sie müssen daher sorgfältig und mit Bedacht konfiguriert werden, um maximale Effizienz zu erreichen, die nicht zu Lasten der Serverstabilität geht.
Der Arbeitsablauf DAM-Update-Asset enthält eine vollständige Reihe von Schritten, die für Aufgaben wie die Dynamic Media-PTIFF-Generierung und Adobe InDesign Server-Integration konfiguriert sind. Die meisten Benutzer benötigen jedoch nicht alle diese Schritte. Adobe empfiehlt, eine benutzerdefinierte Kopie des Workflow-Modells DAM Update Asset zu erstellen und alle unnötigen Schritte zu entfernen. Aktualisieren Sie in diesem Fall die Starter für DAM Update Asset, um auf das neue Modell zu verweisen.
Wenn Sie den Arbeitsablauf DAM-Update-Asset intensiv ausführen, kann die Größe Ihres Dateidatatastors stark erhöht werden. Entsprechende Tests von Adobe haben gezeigt, dass die Datenspeichergröße um ca. 400 GB ansteigt, wenn innerhalb von 8 Stunden 5.500 Workflows ausgeführt werden.
Hierbei handelt es sich um einen vorübergehenden Anstieg. Nach Ausführung der Aufgabe zur Speicherbereinigung weist der Datenspeicher wieder seine ursprüngliche Größe auf.
In der Regel wird die Speicherbereinigung wöchentlich gemeinsam mit anderen geplanten Wartungsaufgaben ausgeführt.
Wenn Sie über einen begrenzten Speicherplatz verfügen und DAM Update Asset intensiv Workflows, sollten Sie die Garbage Collection-Aufgabe häufiger planen.
Kunden verwenden Bilder unterschiedlicher Größen und Formate auf ihrer Website oder zur Weiterleitung an die Geschäftspartner. Da jede Darstellung den Footprint der Assets im Repository vergrößert, empfiehlt Adobe die umsichtige Verwendung dieser Funktion. Um die Menge der Ressourcen zu reduzieren, die für die Verarbeitung und Speicherung von Bildern benötigt wird, können Sie die Bilder statt als Ausgabeformate bei der Erfassung auch zur Laufzeit generieren.
Viele Kunden der Website implementieren ein Bild-Servlet, das Bilder zum Zeitpunkt ihrer Anforderung skaliert und beschneidet und der Veröffentlichungsinstanz damit eine zusätzliche Belastung auferlegt. Wenn diese Bilder zwischengespeichert werden können, lässt sich dieses Problem abmildern.
Eine Alternative besteht darin, die Dynamic Media-Technologie zur gänzlichen Hand-aus-Bild-Manipulation einzusetzen. Darüber hinaus können Sie Markenportal bereitstellen, das nicht nur Verantwortung für die Generierung von Darstellungen aus der Experience Manager-Infrastruktur übernimmt, sondern auch die gesamte Veröffentlichungsstufe.
Wenn Sie den Workflow DAM Update Asset anpassen, um Darstellungen mit ImageMagick zu generieren, empfiehlt Adobe, die policy.xml
-Datei unter /etc/ImageMagick/
zu ändern. Standardmäßig beansprucht ImageMagick den gesamten verfügbaren Speicherplatz auf dem Betriebssystem-Volume sowie den verfügbaren Arbeitsspeicher. Nehmen Sie die folgenden Konfigurationsänderungen im Abschnitt policymap
von policy.xml
vor, um diese Ressourcen zu beschränken.
<policymap>
<!-- <policy domain="system" name="precision" value="6"/> -->
<policy domain="resource" name="temporary-path" value="/ephemeral0/imagemagick_tmp?lang=de"/>
<policy domain="resource" name="memory" value="1000MiB"/>
<policy domain="resource" name="map" value="1000MiB"/>
<!-- <policy domain="resource" name="area" value="1gb"/> -->
<policy domain="resource" name="disk" value="10000MiB"/>
<!-- <policy domain="resource" name="file" value="768"/> -->
<policy domain="resource" name="thread" value="1"/>
<policy domain="resource" name="throttle" value="50"/>
<!-- <policy domain="resource" name="time" value="3600"/> -->
</policymap>
Stellen Sie darüber hinaus in der Datei configure.xml
(alternativ in der Umgebungsvariable MAGIC_TEMPORARY_PATH
) den Pfad zum temporären Ordner von ImageMagick auf eine Festplattenpartition ein, die über ausreichend Speicherplatz und IOPS verfügt.
Eine falsche Konfiguration kann den Server instabil machen, wenn ImageMagick sämtlichen verfügbaren Festplattenspeicher verwendet. Die zur Verarbeitung großer Dateien mit ImageMagick erforderlichen Richtlinienänderungen können sich auf die Leistung von Experience Manager auswirken. Weitere Informationen finden Sie unter Installieren und Konfigurieren von ImageMagick.
Die ImageMagick-Dateien policy.xml
und configure.xml
stehen unter /usr/lib64/ImageMagick-*/config/
anstelle von /etc/ImageMagick/
zur Verfügung. Informationen zum Speicherort der Konfigurationsdateien finden Sie in der ImageMagick-Dokumentation.
Wenn Sie Experience Manager unter Adobe Managed Services (AMS) verwenden, wenden Sie sich an den Kundendienst, wenn Sie eine große Anzahl von PSD- oder PSB-Dateien verarbeiten möchten. Wenden Sie sich an den Kundenbetreuer der Adobe, um diese Best Practices für Ihre AMS-Bereitstellung zu implementieren und die bestmöglichen Tools und Modelle für die proprietären Formate der Adobe auszuwählen. Experience Manager kann keine sehr hochauflösenden PSB-Dateien mit mehr als 30000 x 23000 Pixel verarbeiten.
Durch XMP Schreibback wird das ursprüngliche Asset bei jeder Änderung der Metadaten in Experience Manager aktualisiert. Dies führt zu Folgendem:
Die aufgeführten Ergebnisse beanspruchen umfangreiche Ressourcen. Daher empfiehlt Adobe, XMP-Writeback zu deaktivieren, wenn es nicht benötigt wird.
Wenn Sie eine große Menge an Metadaten importieren, kann es zu ressourcenintensiven XMP-Writeback-Aktivitäten kommen, falls das Flag für laufende Workflows gesetzt ist. Planen Sie einen solchen Import während Zeiten geringer Servernutzung, damit die Leistung anderer Benutzer nicht beeinträchtigt wird.
Wenn Sie Assets in einer große Menge an veröffentlichten Instanzen replizieren (beispielsweise in einer Sites-Implementierung), empfiehlt Adobe die Kettenreplikation. In diesem Fall wird die Autorinstanz in eine einzelne Veröffentlichungsinstanz repliziert, die wiederum in die anderen Veröffentlichungsinstanzen repliziert wird und so die Autorinstanz freihält.
Adobe rät von der automatischen Aktivierung von Assets ab. Falls jedoch notwendig, sollte dies der letzte Schritt in einem Workflow, normalerweise „DAM-Update-Asset“, sein.
Installieren Sie die neuesten Service Packs und leistungsbezogene Hotfixes, da diese häufig Aktualisierungen von Systemindizes beinhalten. Einige Indexoptimierungen finden Sie unter Tipps zur Leistungsoptimierung.
Erstellen Sie eigene Indizes für Abfragen, die Sie häufig ausführen. Weitere Informationen finden Sie unter Methoden zur Analyse von langsamen Abfragen und Erstellen benutzerdefinierter Indizes. Weitere Einblicke in Best Practices bezüglich Abfragen und Indizes finden Sie unter Best Practices für Abfragen und Indizierung.
Einige Optimierungen können mit den Oak Index Konfigurationen durchgeführt werden, die die Leistung von Experience Manager Assets verbessern können. Aktualisieren Sie die Indexkonfigurationen, um die Neuindizierungszeit zu verbessern:
/crx/de/index.jsp
und melden Sie sich als Administrator an./oak:index/lucene
.String[]
-Eigenschaft excludedPaths
mit den Werten /var
, /etc/workflow/instances
und /etc/replication
./oak:index/damAssetLucene
. hinzufügen einer String[]
-Eigenschaft includedPaths
mit dem Wert /content/dam
. Speichern Sie die Änderungen.Wenn Ihre Benutzer keine Volltextsuche von Assets durchführen müssen, z. B. durch Durchsuchen von Text in PDF-Dokumenten, deaktivieren Sie diese Option. Sie verbessern die Indexleistung, indem Sie die Indexierung im Volltext deaktivieren. Gehen Sie wie folgt vor, um die Apache Lucene-Extraktion zu deaktivieren:
Verwenden Sie beim Erstellen von Abfragen mit großen Ergebnismengen den Parameter guessTotal
, um eine übermäßige Belastung des Arbeitsspeichers bei der Ausführung zu vermeiden.
Zwei bekannte Probleme beziehen sich auf große Dateien in Experience Manager. Bei Dateien, die größer als 2 GB sind, kann eine kalte Standby-Synchronisierung zu einem Speicherengpass führen. In einigen Fällen wird die Ausführung der Standby-Synchronisierung verhindert. In anderen Fällen stürzt die primäre Instanz ab. Dieses Szenario gilt für alle Dateien in Experience Manager, die größer als 2 GB sind, einschließlich Inhaltspakete.
Genauso kann es bei Dateien mit einer Größe von 2 GB bei Verwendung eines freigegebenen S3-Datenspeichers einige Zeit dauern, bis die Datei vollständig vom Cache zum Dateisystem beibehalten wird. Wenn Sie die Binaryless-Replikation verwenden, kann es passieren, dass die binären Daten vor dem Abschluss der Replikation nicht dauerhaft gespeichert werden. Diese Situation kann zu Problemen führen, insbesondere wenn es auf hohe Datenverfügbarkeit ankommt.
Für jede Experience Manager-Bereitstellung richten Sie ein Leistungstestsystem ein, das Engpässe schnell erkennen und beheben kann. Konzentrieren Sie sich dabei auf die folgenden Schlüsselaspekte.
Führen Sie für alle Aspekte, die die für Kunden relevante Netzwerkleistung betreffen, die folgenden Aufgaben aus:
Um Latenzzeiten zu minimieren und durch effiziente CPU-Auslastung und Lastenverteilung einen hohen Durchsatz zu erzielen, sollten Sie die Leistung Ihrer Experience Manager-Bereitstellung regelmäßig überwachen. Führen Sie insbesondere die folgenden Aufgaben aus: