AEM 6.x | Conseils sur l’optimisation des performances

Découvrez des stratégies efficaces et des conseils pour optimiser les performances de Adobe Experience Manager (AEM), les tests de chargement, les paramètres JVM et le réglage du cache.

Description description

Environnement

  • Adobe Experience Manager 6.4
  • Adobe Experience Manager 6.5

Problème/Symptômes

Le temps de réponse est faible lorsque les auteurs modifient du contenu ou que les sites web répondent lentement aux demandes des visiteurs.

Ces conseils d’optimisation des performances peuvent vous aider à accélérer les requêtes et les performances.

Cause

Les facteurs suivants influent sur les problèmes de performances dans AEM :

  • Conception incorrecte
  • Code de l’application
  • Absence de mise en cache
  • Configuration d’E/S de disque incorrecte
  • Dimensionnement de mémoire
  • Bande passante réseau et latence
  • AEM installé sur certaines versions sélectionnées de Windows 2008 et 2012 où la gestion de la mémoire est un problème
  • La modification des configurations prêtes à l’emploi comme décrit ci-dessous peut améliorer les performances dans AEM.

Résolution resolution

Prévention des problèmes de performances

Voici quelques étapes que vous pouvez suivre pour vous assurer que vous recherchez et corrigez les problèmes de performances avant qu’ils n’aient un impact sur vos utilisateurs :

  1. Mettez en oeuvre et exécutez des tests de charge qui simulent des scénarios réalistes dans les instances de création et de publication. La recherche et la définition de la charge attendue sont une étape essentielle de ce processus. Cette étape vous permet de démontrer si l’installation de l’application, de l’architecture et de l’AEM d’AEM fonctionnera correctement une fois qu’elle sera en ligne dans un environnement de production.
    Les résultats de cet exercice permettent de déterminer s’il existe une erreur de configuration, un problème d’application, un problème de dimensionnement, un problème matériel ou un autre problème affectant les performances du système. Voir aussi directives relatives aux performances et directives de surveillance.

  2. Outre les tests de charge, les tests de stress permettent de définir la charge maximale que le système peut traiter. Ce test peut vous aider à vous préparer aux pics de trafic. Vous trouverez plus d’informations sur les tests de performance here.

  3. Installez les Service Packs d’AEM recommandés, les correctifs cumulatifs et les correctifs logiciels : Mises à jour de la version Adobe Experience Manager.

  4. Si vous utilisez un serveur Windows, consultez cet article.

  5. Si vous envisagez de charger de grandes quantités de ressources (images, vidéos, etc.) dans AEM, veillez à appliquer la variable Bonnes pratiques relatives aux ressources.

  6. Configuration de suffisamment de mémoire vive et éviter la saturation des E/S
    Si vous envisagez d’exécuter la production à n’importe quelle échelle, l’environnement Linux doit être configuré avec autant de RAM que les fichiers tar de segment vont s’étendre entre le compactage hors ligne (ou les pics de compactage en ligne). En outre, ce qui suit permet d’éviter la saturation des E/S.

    • Séparation des systèmes d’exploitation, des données et des disques de journalisation
    • Montez les disques de données avec Noatime.
    • Définissez les tampons de lecture anticipée sur 32 sur le disque de données.
    • Idéalement, utilisez XFS sur ext4 sur les disques de données.
    • Si RedHat s'exécute dans une machine virtuelle, assurez-vous que le pool d'entropie est toujours > 1K bits (utilisez rngtools si nécessaire)
  7. Désactivation de Transparent Huge Pages sous Linux
    AEM effectue des lectures/écritures précises, tandis que les pages transparentes Linux sont optimisées pour les opérations volumineuses. Il est donc recommandé de désactiver Transparent Huge Pages lors de l’utilisation du stockage Mongo ou Tar.

  8. Activation des workflows transitoires
    Les workflows transitoires peuvent être utilisés pour tous les workflows qui :

    • sont exécutées fréquemment ;
    • n’ont pas besoin de l’historique des workflows.

    Elles génèrent une amélioration des performances dans ces situations.
    Ce cas d’utilisation est généralement rencontré lorsqu’il existe de gros volumes d’assimilation de ressources.
    Suivez la procédure décrite à la section Réglage des performances des ressources.

  9. Réglage des files d’attente de tâche Sling
    Le chargement en masse de ressources volumineuses est généralement un processus très gourmand en ressources. Par défaut, le nombre de threads simultanés par file d’attente de tâche est égal au nombre de coeurs de processeur. Par conséquent, ce paramètre de valeur peut avoir un impact global sur les performances et une consommation élevée de tas Java.
    Adobe recommande de ne pas dépasser 50 % des coeurs de processeur. Pour ajuster cette valeur, accédez à la page suivante : https:/host:port/system/console/configMgr/org.apache.sling.event.jobs.QueueConfiguration Set queue.maxparallel à une valeur représentant 50 % des coeurs de processeur du serveur hébergeant votre instance AEM. Par exemple, pour 8 coeurs de processeur, définissez la valeur sur 4.

  10. Réglage de votre référentiel Oak
    Assurez-vous d’abord que la dernière version d’Oak est installée pour votre instance AEM 6. Consultez la page des correctifs recommandés mentionnés ci-dessus.

    Optimisations du moteur de requête/index Oak

    • Créez des index oak personnalisés pour toutes les requêtes de recherche fréquemment utilisées.

      • Pour plus d’informations sur l’analyse des requêtes lentes, reportez-vous à cette section article.
      • Créez les index personnalisés sous le noeud oak:index pour toutes les propriétés de recherche avec lesquelles vous souhaitez effectuer une recherche en procédant comme suit : article.
      • Pour chaque index personnalisé basé sur Lucene, essayez de définir le paramètre includedPaths (String) afin de restreindre l’index à appliquer uniquement à certains chemins de contenu. Puis, restreignez les recherches applicables aux chemins inclus par l’index.
    • Paramètres JVM
      Ajoutez ces paramètres JVM dans le script de démarrage AEM afin d’éviter que les requêtes expansives ne surchargent les systèmes. Notez qu’il s’agit de valeurs par défaut à partir de AEM 6.3.

      • Doak.queryLimitInMemory=500000 (voir également Documentation Oak)
      • Doak.queryLimitReads=100000 (voir également Documentation Oak)
      • Dupdate.limit=250000 (uniquement pour DocumentNodeStore, par exemple). MongoMK, RDBMK)

      L’option suivante peut également améliorer les performances, mais modifie la signification de l’appel de taille du résultat. En particulier, seules les restrictions de requête qui font partie de l’index utilisé sont prises en compte lors du calcul de la taille.
      En outre, les listes de contrôle d’accès ne sont pas appliquées aux résultats. Par conséquent, les noeuds qui ne sont pas visibles pour la session en cours seront toujours inclus dans le nombre renvoyé. Ainsi, le nombre renvoyé peut être supérieur au nombre réel de résultats et le nombre exact ne peut être déterminé qu’en effectuant une itération sur les résultats :

      Attention : Activation fastQuerySize entraîne des réponses de requête plus rapides. Toutefois, AEM renvoie des résultats inexacts pour certaines requêtes. Si vous comptez sur des résultats précis dans votre application, n’utilisez pas fastQuerySize.

    • Configuration de l’index Lucene
      Ouvrez /system/console/configMgr/org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProviderService et

      • enable CopyOnRead (activé par défaut depuis AEM 6.2)
      • enable CopyOnWrite (activé par défaut depuis AEM 6.2)
      • enable Prérécupération des fichiers d’index (activé par défaut depuis AEM 6.2)

      Voir https://jackrabbit.apache.org/oak/docs/query/lucene.html pour plus d’informations sur les paramètres disponibles. Comme certains chemins n’ont pas besoin d’être indexés, vous pouvez effectuer les opérations suivantes : en CRXDE Lite, accédez à /oak:index/lucene, définissez une propriété de chaîne à plusieurs valeurs (String) nommée excludedPaths avec ces valeurs /var, /etc/workflow/instances, /etc/replication.

    • Entrepôt de données
      Si vous utilisez AEM Assets ou si vous disposez d’une application AEM qui utilise des fichiers binaires de manière intensive, Adobe vous recommande d’utiliser une banque de données externe. L’utilisation d’une banque de données externe permet d’optimiser les performances. Voir documentation pour obtenir des instructions détaillées.
      Lors de l’utilisation d’un FileDataStore, définissez cacheSizeInMB sur un pourcentage de votre tas disponible. Une valeur conservatrice est de 2 % du tas maximal. Par exemple, pour un tas de 8 Go :

      • maxCachedBinarySize=1048576
      • cacheSizeInMB=164

      Notez que maxCachedBinarySize est défini sur 1 Mo (1048576). Ainsi, il ne met en cache que les fichiers d’un maximum de 1 Mo. Il peut également être judicieux de définir ce paramètre sur une valeur plus petite.
      Lorsque vous traitez un grand nombre de fichiers binaires, vous souhaitez optimiser les performances. Par conséquent, Adobe recommande d’utiliser une banque de données externe au lieu des magasins de noeuds par défaut. Adobe vous recommande en outre d’ajuster les paramètres suivants :

      • maxCachedBinarySize=10485760
      • cacheSizeInMB=4096

      Remarque : La variable cacheSizeInMB peut entraîner une insuffisance de mémoire du processus Java s’il est trop élevé. Par exemple, si la taille maximale du segment de mémoire est définie à 8 Go (-Xmx8g) et que vous prévoyez que AEM et votre application utilisent un segment de mémoire combiné de 4 Go, il est logique de définir cacheSizeInMB sur 82 au lieu de 164. Dans la plage de 2 à 10 % du tas maximal est une configuration sûre. Cependant, Adobe vous recommande de valider les modifications de paramètre avec le test de charge tout en surveillant l’utilisation de la mémoire.

  11. Réglage du stockage Mongo

    • Taille du cache MongoBlobStore : Le blobstore est utilisé pour stocker et lire des objets binaires volumineux. En interne, le magasin avec cache est mis en oeuvre, ce qui divise les binaires en blocs relativement petits (données, code de hachage ou hachage indirect), de sorte que chaque bloc tienne dans la mémoire. Dans une configuration par défaut, le MongoBlobStore utilise une taille de cache fixe de 16 Mo. Pour les déploiements où plus de RAM est disponible et où le stockage blob est fréquemment utilisé (par exemple, lorsque l’index Lucene est volumineux), augmentez la taille du cache. Cette taille de cache s’applique uniquement lorsque vous utilisez MongoBlobStore (par défaut), et non lors de l’utilisation d’un blobstore externe.

      • Vous pouvez configurer la taille du cache (en Mo) au moyen du paramètre blobCacheSize sur DocumentNodeStoreService.
        Par exemple : blobCacheSize=1024
      • Veuillez également consulter AEM-MongoDB liste de contrôle.
    • Taille du cache du document : Pour optimiser les performances des noeuds de lecture de MongoDB, vous devez régler les tailles de cache de DocumentNodeStore. La taille par défaut du cache est définie sur 256 Mo, qui est répartie entre les différents caches utilisés dans DocumentNodeStore. Voir http://jackrabbit.apache.org/oak/docs/nodestore/documentmk.html#cache

      • Vous pouvez configurer la taille du cache (Mo) au moyen du paramètre de cache sur DocumentNodeStoreService. Par exemple, cache=2048.

      • Définissez toutes les configurations de cache suivantes dans crx-quickstart/install/org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.config, puis effectuez un test de chargement avec différentes valeurs afin de voir quelle est la configuration optimale pour votre environnement. Notez que le pourcentage de cache restant est donné au cache du document :

        • cache=2048
        • nodeCachePercentage=35
        • childrenCachePercentage=20
        • diffCachePercentage=30
        • docChildrenCachePercentage=10
      • Avec la configuration ci-dessus, les pourcentages sont de 95 %. Les 5 % restants du cache sont attribués à documentCache. documentCache = cache - nodeCache - childrenCache - diffCache - docChildrenCache

      • Lors de la distribution des pourcentages de cache, assurez-vous que le cache laissé pour documentCache n’est pas très volumineux. En d’autres termes, conservez-le à 500 Mo max. ou moins ; un documentCache volumineux peut entraîner une augmentation du temps nécessaire à l’invalidation du cache.

    • Paramètres de cache dans AEM 6.2 avec Oak 1.4.x :

      • Dans AEM 6.2, des modifications ont été apportées à la façon dont ces paramètres de cache fonctionnent. Dans AEM 6.2 avec Oak 1.4, il existe un nouveau cache : prevDocCache. Vous pouvez configurer ce cache à l’aide du paramètre prevDocCachePercentage. La valeur par défaut est 4.
      • DocumentCache utilise le reste du cache MB (paramètre de cache moins la taille de tous les autres caches) : documentCache = cache - nodeCache - childrenCache - diffCache - docChildrenCache - prevDocCache
    • Implémentez la liste de contrôle de production MongoDB :
      https://docs.mongodb.org/manual/administration/production-checklist/ - selon la prise en charge de Mongo DB, de nombreux éléments ont un impact important sur les performances. Pour toute question, contactez directement le support MongoDB.

    • Performances de lecture : Ajoutez ce paramètre de chaîne de requête à votre URL Mongo DB sur chaque noeud AEM : ?readPreference=secondaryPreferred
      Ce paramètre indique au système d’effectuer des lectures à partir du secondaire, ce qui donne des performances de lecture supplémentaires.

    • Augmentez le pool de threads pour l’observation Oak : open /system/console/configMgr/org.apache.sling.commons.threads.impl.DefaultThreadPool.factory Définissez le nom sur oak-observation et la taille du pool min. et max. sur 20.

    • Augmentez la longueur de la file d’attente d’observation : Créez un fichier nommé com.adobe.granite.repository.impl.SlingRepositoryManager.cfg paramètre contain oak.observation.queue-length=50000. Placez-le sous le /crx—quickstart/install dossier.

    • Évitez les requêtes de longue durée : définissez la propriété système dans les paramètres JVM : -Doak.mongo.maxQueryTimeMS=60000 pour éviter que les requêtes ne s’exécutent pendant plus d’une minute.

  12. Optimisation du stockage tar
    Les micronoyaux n’appellent pas directement les fichiers mappés en mémoire. Toutefois, JDK utilise en interne des fichiers mappés en mémoire pour une lecture efficace. Sur certains systèmes d’exploitation Windows 64 bits, il se peut que le nettoyage des fichiers mappés en mémoire échoue et que la mémoire du système d’exploitation natif soit utilisée. Veillez à installer les correctifs/correctifs liés aux performances à partir de microsoft (voir 2731284 de base) et Oracle.

    Une autre option consiste à désactiver le mode de carte mémoire en ajoutant tarmk.mode=32 in SegmentNodeStoreService.config jusqu’à ce que le problème du système d’exploitation soit résolu. L’inconvénient de la désactivation rend les E/S intensives. Veillez à augmenter la limite de verrouillage de page E/S.

  13. Nettoyage de la révision TarMK (compaction)
    À compter d’AEM 6.3, la compression en ligne (également appelée nettoyage des révisions en ligne) est activée par défaut. Pour plus d’informations, consultez cette page.

  14. Cloud Manager pour les clients Adobe Managed Services (AMS)
    Cloud Manager (Clients AMS uniquement) permet aux clients d’assurer un déploiement AEM réussi avec des tests de performances guidés et la mise à l’échelle automatique.

recommendation-more-help
3d58f420-19b5-47a0-a122-5c9dab55ec7f