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

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 également les directives de performances et les directives de surveillance.

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 ici.

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

Si vous utilisez un serveur Windows, passez en revue cet article.

Si vous envisagez de charger de grandes quantités de ressources (images, vidéos, etc.) dans AEM, veillez à appliquer les bonnes pratiques Assets.

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)

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.

Activation des workflows transitoires
Les workflows transitoires peuvent être utilisés pour tout workflow 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 dans Optimisation des performances Assets.

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 à : https:/host:port/system/console/configMgr/org.apache.sling.event.jobs.QueueConfiguration
Définissez queue.maxparallel sur une valeur qui représente 50 % des coeurs de processeur du serveur qui héberge votre instance AEM. Par exemple, pour 8 coeurs de processeur, définissez la valeur sur 4.

Optimisation 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, consultez cet article.
  • Créez les index personnalisés sous le noeud oak:index pour toutes les propriétés de recherche que vous souhaitez rechercher en suivant cet 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 aussi Documentation Oak)
  • Doak.queryLimitReads=100000 (voir également la 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 :

  • Doak.fastQuerySize=true (voir aussi la taille des résultats dans la documentation Oak)

  Attention : L’activation de 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

  • Activez CopyOnRead (activé par défaut depuis AEM 6.2)
  • Activez CopyOnWrite (activé par défaut depuis AEM 6.2)
  • Activez la fonction de prérécupération des fichiers d’index (activée 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 :
  Dans 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. Consultez la 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 : Le paramètre 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.

Réglage du stockage Mongo

• Taille du cache MongoBlobStore : La banque de données Blobstore est utilisée 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 checklist.

• Taille du cache du document : Pour optimiser les performances de lecture des noeuds de MongoDB, vous devez régler la taille des caches 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

• Mettez en oeuvre 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.

• Augmenter le pool de threads pour l’observation Oak-observation : ouvrez /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.

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

• É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.

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 KB 2731284) et Oracle.

Une autre option consiste à désactiver le mode de mappage de la mémoire en ajoutant tarmk.mode=32 dans 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.

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. Voir cette page pour plus d’informations.

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