Allgemeine Probleme und Lösungen bei der Asset-Aufnahme

In diesem Artikel werden die gängigsten problematischen AEM-Assets-Aufnahmeszenarien und deren Analyse beschrieben.

• Hohe Verarbeitung
• Hohes Volumen
• Große DAM-Repositories
• Viele gleichzeitige Autoren
  
  

Einnahme-Szenario und Lösungen

Szenario 1: Hohe Verarbeitung

Situationen, etwa bei Massenimporten, z. B. 2000 Bilder auf einmal, verursachen Autoreninstanzen hohe CPU- und Speicherkapazität.

Lösung:Aufträge an 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 Instanz des Autors bleibt weiterhin für andere Benutzer frei. DAM-Proxy-Workers überwachen entfernte Aufgaben, sammeln die Ergebnisse und leiten sie an die lokale Workflow-Ausführung weiter.

Szenario 2: Hohes Volumen

Instanzen, wo Datenbanken mit wenigen Millionen Produkten, die 12.000 Modifikationen pro Tag haben. Das Repository wird zum Engpass in solchen Szenarios. Während Schreibvorgänge stattfinden, werden Lesevorgänge aus Gründen der Konsistenz blockiert.

Lösung: Um diese Situation zu vermeiden, trennen Sie den Importvorgang von einer dedizierten Autoreninstanz mit einem eigenen Repository. Bei Abschluss replizieren Sie ein vollständiges Delta in die Autorenumgebung mit einer verketteten Replikation in die Veröffentlichungsumgebung, falls erforderlich. Verwenden Sie eine reservierte Replikationswarteschlange, um zu vermeiden, dass wichtige redaktionelle Änderungen aus der Veröffentlichung verzögert werden.

Szenario 3: Große DAM-Repositorys. Riesige Repositories, solche mit über 7 Millionen Assets, 20 Millionen Knoten und 15 TB Festplattengröße. Dies wirkt sich auf die Leistung 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 niedriger Latenz, daher funktioniert der lokale Speicher am besten. Für den Datenspeicher ist eine höhere Latenz zulässig.

Szenario 4: Viele gleichzeitige Autoren können die Leistung und die Verarbeitung beeinträchtigen.

Lösung: Gleichzeitige Autoren sind Benutzer, die aktiv an dem System arbeiten. Eingeloggte, aber inaktive Autoren belasten das System nicht zusätzlich. Operationen wie Bearbeiten, Hochladen von Assets, Auslösen von Workflows CPU, Speicher, Suchen und Herunterladen von Assets, Ändern von Metadaten. Durch das Erstellen eines Clusters von Autoreninstanzen mit einem Dispatcher vorne wird die CPU-Last gleichmäßig verteilt. Bei einer großen Anzahl von Autoren in aktiver Produktion wird empfohlen, jedes Projekt in eine separate Autoreninstanz oder -umgebung zu zerlegen, in der die laufenden Arbeiten stattfinden. Dieses Verfahren heißt „partitioning“.