Häufige Probleme und Lösungen bei der Erfassung von Assets

In diesem Artikel werden die häufigsten Problemszenarien für die Aufnahme von AEM-Assets beschrieben und wie diese analysiert werden können, einschließlich hoher Verarbeitung, hohem Volumen, großen DAM-Repositorys und vielen gleichzeitigen Autorinnen und Autoren.

Beschreibung description

Umgebung

Adobe Experience Manager (AEM)

Problem

In diesem Artikel werden die häufigsten Problemszenarien für die Aufnahme von AEM-Assets beschrieben und wie sie für Folgendes analysiert werden können:

Auflösung resolution

Aufnahmeszenarien und -lösungen

Szenario 1: Hohe Verarbeitungsrate

Situationen wie Massenimporte, z. B. 2.000 Bilder gleichzeitig, führen zu einer hohen CPU- und Speicherkapazität der Autoreninstanzen.

Lösung

Aufträge auf eine andere AEM-Instanz auslagern. Sie können ganze Workflows oder nur wenige schwere Schritte auslagern, indem Sie die Verarbeitungsinstanz über DAM-Proxy-Worker mit den primären Autoreninstanzen verbinden. Die primäre Autoreninstanz bleibt dabei frei, um andere Benutzer zu bedienen. DAM-Proxy-Worker sind für die Überwachung von Remote-Aufgaben, die Erfassung der Ergebnisse und die Weiterleitung an die lokale Workflow-Ausführung zuständig.

Szenario 2: Hohes Volumen​

Dies sind Fälle, in denen eine Datenbank mit ein paar Millionen Produkten, die 12.000 Änderungen pro Tag haben. Das Repository wird in solchen Szenarien zum Engpass. Während Schreibvorgänge ausgeführt werden, werden Lesevorgänge aus Konsistenzgründen blockiert.

Lösung

Um dies zu verhindern, trennen Sie den Importvorgang auf einer dedizierten Autoreninstanz von einem eigenen Repository. Replizieren Sie nach Abschluss des Vorgangs ein vollständiges Delta in die Autorenumgebung, ggf. mit verketteter Replikation in die Veröffentlichungsumgebung. Verwenden Sie eine reservierte Replikations-Warteschlange, um zu vermeiden, dass wichtige redaktionelle Änderungen aus der Veröffentlichung verzögert werden.

Szenario 3: Große DAM-Repositorys

Dies geschieht bei großen Repositorys, z. B. über 7 Millionen Assets, 20 Millionen Knoten und einer Festplattengröße von 15 TB. Dies wirkt sich auf die Leistung der Instanz aus.

Lösung

Teilen Sie den persistenten Speicher und den Datenspeicher (optimiert für die Verarbeitung großer Binärdateien). Der persistente Speicher erfordert I/O mit sehr geringer Latenz, daher funktioniert der lokale Speicher am besten. Für den Datenspeicher ist eine höhere Latenz akzeptabel.

Szenario 4: Viele gleichzeitige Autoren

Viele gleichzeitige Autoren und Autorinnen können die Leistung und Verarbeitung beeinträchtigen.

Lösung

Gleichzeitige Autoren sind Benutzer, die aktiv an dem System arbeiten. Angemeldete, aber inaktive Autoren belasten das System nicht zusätzlich. Vorgänge wie Bearbeiten, Hochladen von Assets, Trigger-Workflows, CPU-Speicher, Suchen und Herunterladen von Assets und Ändern von Metadaten.

Durch die Bildung eines Clusters aus Autoreninstanzen mit einem vorgeschalteten Dispatcher kann die CPU-Last gleichmäßig verteilt werden. Da sich eine große Anzahl von Autoren in der aktiven Produktion befindet, wird empfohlen, jedes Projekt in eine separate Autoreninstanz oder Umgebung zu rotieren, in der die laufende Arbeit stattfindet. Diese Technik wird als Content-Partitionierung bezeichnet.

Stellen Sie Fragen in unserer Experience League-Campaign-Community

Wenn Sie Fragen zu diesem Thema haben oder bereits beantwortete Fragen lesen möchten, laden wir Sie ein, unseren Experience League-Community-Blogpost zu sehen, der diesen Artikel enthält, uns Ihre Fragen und Kommentare zu senden und unserer Experience League-Campaign-Community beizutreten!