DokumentationAEM-Mustererkennung

ASO aso

Last update: Fri Jul 12 2024 00:00:00 GMT+0000 (Coordinated Universal Time)
  • Themen:

Erstellt für:

  • Entwickler

AEM-System-Überblick

Hintergrund background

ASO identifiziert allgemeine Informationen über die AEM-Instanz. Jedes Ergebnis liefert einen Wert eines bestimmten Typs von Systeminformationen.

Um die verschiedenen Arten von Informationen zu erkennen, werden folgende Untertypen verwendet:

  • aem.version: Die AEM-Version.
  • aem.product: Erkennung der Verwendung eines AEM-Produkts (Commerce, Forms usw.).
  • node.count: Die ungefähre Knotenanzahl eines bestimmten Typs (Seite, Asset usw.) und die Gesamtanzahl der Knoten.
  • node.store: Der Implementierungstyp des Knotenspeichers (SegmentNodeStore, DocumentNodeStore) und seine Größe.
  • data.store: Der Speicherimplementierungstyp der Daten (FileDataStore, S3DataStore, AzureDataStore).
  • maintenance.task: Eine Wartungsaufgabe.
  • slow.query: Eine langsame Abfrage.
  • group.membership: Die Anzahl der Benutzenden und Untergruppen (nur direkte/deklarierte Mitglieder) in einer Gruppe.
  • cqtag.count: Die Anzahl der mit CQ-Tags versehenen Assets.
  • smarttag.count: Die Anzahl der mit Smart-Tags versehenen Assets.
  • ccom.version: Die Version des Kernkomponenten-Pakets.
  • instance.type: Der AEM-Instanztyp (author|publish).
  • unprocessed.asset.count: Die Anzahl der nicht verarbeiteten Assets.
  • vanity.url.count: Die Anzahl der Vanity-URLs.
  • index.size: Gesamtgröße des migrierbaren Lucene-Index.
  • workflow.count: Die Anzahl der laufenden und veralteten Author-Workflows.
  • jvm.arguments: Die JVM-Argumente, die beim Starten von AEM zur Befehlszeile hinzugefügt wurden.

Mögliche Auswirkungen und Risiken implications-and-risks

  • Die AEM-Version, die Anzahl der Knoten, die Gruppenmitgliedschaft, der Knotenspeicher, die Implementierungstypen des Datenspeichers, die Anzahl der CQ-Tags, die Anzahl der Smart-Tags, die Kernkomponenten-Version, der AEM-Instanztyp und die Zahl der nicht verarbeiteten Assets werden zu Informationszwecken bereitgestellt.
  • Die höhere Anzahl von Vanity-URLs (>1000) kann den Dispatcher und die Veröffentlichungs-Server mit teuren Abfragen belasten.
  • Das benutzerdefinierte Programm kann auf Produkte oder Funktionen zurückgreifen, die nicht in AEM as a Cloud Service verfügbar sind.
  • Ein Upgrade mit nicht unterstützten Funktionen kann zu einem fehlgeschlagenen Upgrade und einem nicht funktionsfähigen Programm führen.
  • Eine hohe Anzahl von Autoren-Workflows im laufenden oder veralteten Zustand könnte die Leistung beeinträchtigen.
  • Langsame Abfragen können die Systemleistung beeinträchtigen.

Mögliche Lösungen solutions

  • AEM-Upgrades mit nicht unterstützten Produkten oder Funktionen werden nicht empfohlen und möglicherweise nicht unterstützt.
  • Die unverarbeiteten Assets müssen verarbeitet werden und die Eigenschaft dam:assetState auf dem Knoten jcr:content des Assets muss auf „verarbeitet“ festgelegt werden. Alternativ sollten Sie diese Assets aus dem Migrationssatz entfernen, bevor Sie zu AEMaaCS migrieren.
  • Vanity-URLs können durch Apache-Neuschreibungen ersetzt werden.
  • Siehe die Dokumentation zur Fehlerbehebung bei langsamen Abfragen.
  • Weitere Informationen finden Sie in den Versionshinweisen, wenn Sie mehr über die neuesten Änderungen in AEM as a Cloud Service erfahren möchten.
  • Wenden Sie sich an unser AEM-Supportteam, um weitere Informationen zu erhalten oder um Anliegen vorzubringen.
recommendation-more-help
c50d24a5-718e-4110-a484-b335e8a63206