ASO aso

AEM System Overview (vue d’ensemble du système AEM)

Contexte background

ASO identifie les informations générales de l’instance AEM. Chaque recherche fournit une valeur d’un type particulier d’informations système.

Des sous-types sont utilisés pour identifier les différents types d’informations :

  • aem.version : version d’AEM.
  • aem.product : détection de l’utilisation d’un produit AEM (Commerce, Forms, etc.).
  • node.count : nombre approximatif de nœuds d’un certain type (Page, Ressource, etc.) et total général des nœuds.
  • node.store : type d’implémentation de l’entrepôt de nœuds (SegmentNodeStore, DocumentNodeStore) et sa taille.
  • data.store : type d’implémentation de l’entrepôt de données (FileDataStore, S3DataStore, AzureDataStore).
  • maintenance.task : tâche de maintenance.
  • slow.query : requête lente.
  • group.membership : nombre d’utilisateurs et de sous-groupes (membres directs/déclarés uniquement) dans un groupe.
  • cqtag.count : nombre de ressources avec balisage CQ.
  • smarttag.count : nombre de ressources avec balisage intelligent.
  • ccom.version : version du package de composants principaux.
  • instance.type : type d’instance AEM (auteur, publication).
  • unprocessed.asset.count : nombre de ressources non traitées.
  • vanity.url.count : nombre d’URL de redirection vers un microsite.
  • index.size : taille totale de l’index Lucene pouvant être migré.
  • workflow.count : nombre de workflows de création en cours d’exécution et périmés.
  • jvm.arguments : arguments JVM ajoutés à la ligne de commande lors du démarrage d’AEM.

Enjeux et risques possibles implications-and-risks

  • La version d’AEM, le nombre de nœuds, l’appartenance à un groupe, le magasin de nœuds, les types d’implémentation du magasin de données, le nombre de balises CQ et de balises intelligentes, la version des composants principaux, le type d’instance AEM et le nombre de ressources non traitées sont fournis à titre d’information.
  • Le nombre plus élevé d’URL de redirection vers un microsite (>1 000) peut charger les serveurs Dispatcher et Publish avec des requêtes coûteuses.
  • L’application personnalisée peut s’appuyer sur des produits ou des fonctionnalités qui ne sont pas disponibles dans AEM as a Cloud Service.
  • La mise à niveau avec des fonctionnalités non prises en charge peut entraîner l’échec de la mise à niveau et une application non fonctionnelle.
  • Un nombre élevé de workflows de création dans un état en cours d’exécution ou obsolète peut dégrader les performances.
  • Des requêtes lentes peuvent réduire les performances du système.

Solutions possibles solutions

  • Les mises à niveau d’AEM avec des produits ou des fonctionnalités non pris en charge ne sont pas recommandées et pourraient ne pas être prises en charge.
  • Les ressources non traitées doivent être traitées et la propriété dam:assetState sur le noeud jcr:content de la ressource doit être définie sur "traitée". Sinon, vous devez supprimer ces ressources du jeu de migration avant de migrer vers AEMaaCS.
  • Les URL de redirection peuvent être remplacées à l’aide de réécritures Apache.
  • Consultez la documentation pour résoudre les problèmes liés aux requêtes lentes.
  • Consultez les notes de mise à jour pour en savoir plus sur les dernières modifications apportées à AEM as a Cloud Service.
  • Contactez l’équipe d’assistance AEM si vous avez besoin de clarifications ou de réponses à vos préoccupations.
recommendation-more-help
c50d24a5-718e-4110-a484-b335e8a63206