AEM 6.x | Conseils de réglage de la performance

Implémentez et exécutez des tests de chargement 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 cruciale de ce processus. Cette étape vous permet de démontrer si l’application AEM, l’architecture et l’installation d’AEM s’exécuteront correctement une fois qu’elles seront en ligne dans un environnement de production.
Les résultats de cet exercice permettent de déterminer s’il existe une configuration incorrecte, un problème d’application, de dimensionnement, un problème matériel ou tout autre problème affectant les performances du système. Voir directives de performance.

En plus des tests de charge, les tests de contrainte permettent de définir la charge maximale que le système peut gérer. 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 AEM recommandés, les packs de correctifs cumulatifs et les correctifs logiciels : Mises à jour de la version de Adobe Experience Manager.

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

Allouer suffisamment de RAM 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 augmenteront entre le compactage hors ligne (ou les pics de compactage en ligne). En outre, les éléments suivants évitent la saturation des E/S.

• Disques de stockage, de données et de journalisation distincts
• Montez des 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 via ext4 sur les disques de données.
• Si RedHat est exécuté sur une machine virtuelle, assurez-vous que le pool d’entropie est toujours > 1 Ko (utilisez rngtools si nécessaire)

Désactiver Transparent Huge Pages sur Linux
AEM effectue des lectures/écritures affinées, tandis que Linux Transparent Huge Pages est optimisé 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.

Ils généreront un coup de pouce aux performances dans ces situations.
Ce cas d’utilisation est généralement satisfait en cas de volumes élevés d’ingestion de ressources.
Suivez la procédure décrite dans Optimisation des performances d’Assets.

Réglage des files d’attente des tâches Sling
Le chargement en masse de ressources volumineuses est généralement un processus qui nécessite de nombreuses ressources. Par défaut, le nombre de threads simultanés par file d’attente de tâches est égal au nombre de cœurs CPU. Par conséquent, ce paramètre de valeur peut avoir un impact sur les performances globales et entraîner une consommation élevée de tas Java.
Adobe recommande de ne pas dépasser 50 % des cœurs CPU. Pour ajuster cette valeur, rendez-vous sur : https:/host:port/system/console/configMgr/org.apache.sling.event.jobs.QueueConfiguration
Définissez queue.maxparallel sur une valeur qui représente 50 % des cœurs CPU du serveur hébergeant votre instance AEM. Par exemple, pour 8 cœurs CPU, définissez la valeur sur 4.

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ée ci-dessus.

Optimisations du moteur de requête/de l’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 nœud oak:index pour toutes les propriétés de recherche que vous souhaitez utiliser en suivant cet article.
  • Pour chaque index Lucene personnalisé, essayez de définir le paramètre includePaths (chaîne) afin de limiter l’index à certains chemins de contenu uniquement. Limitez ensuite les recherches applicables aux chemins d’accès inclus par l’index.

• Paramètres JVM
  Ajoutez ces paramètres JVM dans le script de démarrage d’AEM pour empêcher les requêtes volumineuses de surcharger les systèmes. Notez qu’il s’agit des valeurs par défaut à partir d’AEM 6.3.

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

  L’option suivante pourrait tout aussi bien améliorer les performances, mais elle modifie la signification de l’appel de la 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 nœuds 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 itérant à travers les résultats :

  • Doak.fastQuerySize=true (voir aussi Taille du résultat dans la documentation Oak)

  Attention : l’activation de fastQuerySize accélère le temps de réponse des requêtes. Cependant, AEM renvoie un nombre de résultats inexact pour certaines requêtes. Si vous comptez sur un nombre de 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)
  • Activer CopyOnWrite (activé par défaut depuis AEM 6.2)
  • Activez Prérécupération de 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 d’accès 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 (chaîne) nommée excludePaths avec les valeurs suivantes : /var, /etc/workflow/instances, /etc/replication.

• Magasin de données
  Si vous utilisez AEM Assets ou si vous disposez d’une application AEM qui utilise beaucoup de fichiers binaires, Adobe vous recommande d’utiliser un magasin de données externe. L’utilisation d’un magasin de données externe permet d’assurer des performances optimales. Consultez la documentation pour obtenir des instructions détaillées.
  Lors de l’utilisation d’un FileDataStore, définissez cacheSizeInMB sur un pourcentage du 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 la valeur de maxCachedBinarySize est définie sur 1 Mo (1048576). Par conséquent, il ne met en cache que les fichiers d’une taille maximale de 1 Mo. Il peut également être judicieux de définir ce paramètre sur une valeur inférieure.
  Lorsque vous traitez un grand nombre de fichiers binaires, vous souhaitez optimiser les performances. Par conséquent, Adobe recommande d’utiliser un magasin de données externe au lieu des magasins de nœuds par défaut. En complément, Adobe vous recommande d'ajuster les paramètres suivants :

  • maxCachedBinarySize=10485760
  • cacheSizeInMB=4096

  Remarque : le paramètre cacheSizeInMB peut entraîner une saturation de la mémoire du processus Java s’il est défini sur une valeur trop élevée. Par exemple, si la taille maximale du tas est définie sur 8 Go (-Xmx8g) et que vous prévoyez qu’AEM et votre application utilisent un tas 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 max, c’est une configuration sécurisée. Cependant, Adobe vous recommande de valider les modifications des paramètres avec des tests de charge tout en surveillant l’utilisation de la mémoire.

Réglage du stockage Mongo

• Taille du cache de MongoBlobStore : le blobstore est utilisé pour stocker et lire des objets binaires volumineux. En interne, le magasin avec cache est implémenté, ce qui divise les binaires en blocs relativement petits (données ou code haché ou hachage indirect), de sorte que chaque bloc s'adapte en mémoire. Dans une configuration par défaut, MongoBlobStore utilise une taille de cache fixe de 16 Mo. Pour les déploiements où davantage 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 lorsqu’vous utilisez un entrepôt de grands objets blob externe.

  • Vous pouvez configurer la taille du cache (en Mo) au moyen du paramètre blobCacheSize sur DocumentNodeStoreService.
    Par exemple : blobCacheSize=1024
  • Consultez également la liste de contrôle AEM-MongoDB checklist.

• Taille du cache des documents : pour optimiser les performances de lecture des nœuds à partir de MongoDB, vous devez ajuster les tailles des caches de DocumentNodeStore. La taille par défaut du cache est définie sur 256 Mo, qui sont répartis 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.configet puis chargez le test avec différentes valeurs pour voir quelle est la configuration optimale pour votre environnement. Notez que le pourcentage de cache restant est attribué au cache de documents :

    • cache=2048
    • nodeCachePercentage=35
    • childrenCachePercentage=20
    • diffCachePercentage=30
    • docChildrenCachePercentage=10

  • Avec la configuration ci-dessus, les pourcentages totalisent 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 au maximum. 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 au fonctionnement de ces paramètres de cache. 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 Mo de cache restant (paramètre du cache moins la taille de tous les autres caches) : documentCache = cache - nodeCache - childrenCache - diffCache - docChildrenCache - prevDocCache

• Implémentez la liste de contrôle d’exploitation MongoDB :
  https://docs.mongodb.org/manual/administration/production-checklist/ - Selon la prise en charge de la base de données Mongo, de nombreux éléments ont un impact important sur les performances. Pour toute question, contactez directement l’assistance MongoDB.

• Performances de lecture : ajoutez ce paramètre de chaîne de requête à l’URL de votre base de données Mongo sur chaque nœud AEM : ?readPreference=secondaryPreferred
  Ce paramètre indique au système d’effectuer des lectures à partir du secondaire, ce qui améliore les performances de lecture.

• Augmentez le pool de threads pour oak-observation : ouvrez /system/console/configMgr/org.apache.sling.commons.threads.impl.DefaultThreadPool.factory Définissez le nom sur oak-observation et définissez la taille minimale et maximale du pool 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 les requêtes s’exécutant plus d’une minute.

Réglage du stockage Tar
Les micro-noyaux n’appellent pas directement les fichiers mappés en mémoire. Toutefois, le JDK utilise en interne des fichiers mappés par la 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 par la mémoire échoue et consomme toute la mémoire native du système d'exploitation. Veillez à installer les correctifs/correctifs logiciels liés aux performances à partir de Microsoft (voir Ko 2731284) et d’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 la page I/O.

Nettoyage des révisions TarMK (compression)
À 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 d’Adobe Managed Services (AMS)
Cloud Manager (utilisateurs AMS uniquement) vous permet d’assurer la réussite du déploiement d’AEM avec des tests de performance guidés et une mise à l’échelle automatique.