Remarque :

Vous lisez les conseils d'optimisation des performances de version d'Adobe Experience Manager 6.x. Cet article est également disponible pour la version 5.x.

Le temps de réponse est lent pour l'édition et les demandes des visiteurs

Le temps de réponse est médiocre lorsque les auteurs modifient le contenu ou que les sites Web répondent lentement aux demandes de visiteurs.

Cause

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

  • Conception inadéquate
  • Code d’application
  • Configuration incorrecte du disque I/O
  • Dimensionnement de la mémoire
  • Bande passante réseau et temps de latence
  • AEM installé sur certaines fenêtres sélectionnées des versions 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.

Prévention des problèmes de performances

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

  1. Mettez en place et exécutez les tests de chargement qui simulent les scénarios réalistes dans les occurrences 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 savoir si l’application AEM, l’architecture et l’installation AEM fonctionnent correctement lorsqu’ils sont en direct dans un environnement de production. Les résultats de cet exercice aident à déterminer s'il y a une mauvaise configuration, un problème d'application, un dimensionnement, un problème matériel ou un autre problème affectant les performances du système. Voir aussi les directives de performance et les directives de surveillance

    1. Outre le test de chargement, les tests de rapidité 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.
  2. Installation des packs de service AEM recommandés, des packs de correctif cumulatifs et des correctifs urgents :

    https://helpx.adobe.com/fr/experience-manager/aem-releases-updates.html

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

  4. Si vous prévoyez de charger de grandes quantités de Ressources (images, vidéos, etc.) dans AEM, assurez-vous d’appliquer les meilleures pratiques Ressources.

  5. Fournir suffisamment de RAM et éviter la saturation des entrées-sorties.

    Si vous souhaitez exécuter la production à n’importe quelle échelle, l’environnement Linux doit être mis à l’échelle avec autant de mémoire vive que les fichiers tar de segment, ce qui se traduit par une fragmentation hors ligne (ou des pics de compactage en ligne).  En outre, cette procédure évite la saturation des entrées-sorties.

    • Disques d’exploitation/de données/journaux distincts
    • Montez des disques de données avec noatime
    • Définir les tampons en lecture anticipée sur <32 sur le disque de données.
    • Idéalement, utilisez xfs sur ext4 sur les disques de données.
    • Si Red Hat s'exécute sur une VM, assurez-vous que le pool d'entropie est toujours > 1K bits (utilisez rngtools si nécessaire)
  6. Désactivez Transparent Huge Pages sur Linux

    AEM exécute 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 lorsque vous utilisez le stockage Mongo ou Tar.

Remarque :

Cet article s'applique à AEM 6.x, pour les conseils d'optimisation des performances AEM / CQ 5.6.1 (ou version antérieure), voir https://helpx.adobe.com/fr/experience-manager/kb/performancetuningtips.html.

Activation des flux de travail transitoires

Pour optimiser les chargements d'ingestion élevés, Adobe suggère le basculement de la mise à jour DAM et des métadonnées de réécriture XMP vers un processus transitoire. Comme son nom l’indique, les données d’exécution associées aux étapes de travail intermédiaire dans les processus transitoires ne sont pas conservées dans le JCR lorsqu’elles sont exécutées (les rendus de sortie sont bien sûr conservés). Il en résulte une réduction du temps de traitement du flux de travail de l’ordre de 10 % et une diminution considérable de la croissance du référentiel. Aucun processus CRUD n’est requis pour la purge. En outre, cela réduit le nombre de fichiers TAR à compresser. Si votre entreprise exige la conservation/l’archivage des données d’exécution du flux de travail à des fins d’audit, n’activez pas cette fonctionnalité.

Remarque :

Pour activer les processus transitoires, il faut tenir compte des points suivants :

  • Les processus transitoires ne génèrent pas d’événements de processus. Par conséquent, les fonctions et les clients qui dépendent d'événements ne doivent pas activer les processus transitoires.
  • Les processus transitoires ne prennent pas en charge le déchargement du processus, qui dépend des événements du processus.
  • Les flux de travail transitoires ne prennent pas en charge les événements de flux de travail CQ hérités. La raison est que la couche de compatibilité dans CQEventDispatcher ne fonctionne pas.
  • Les flux de production transitoires ne prennent pas en charge la notification par courrier électronique. La raison est que EmailNotificationService est basé sur CQEventDispatcher, qui ne fonctionne pas avec les flux de production transitoires.
  • Les flux de travail transitoires ne prennent pas en charge les statistiques des flux. La raison est que CQWorkflowStatisticsService est basé sur CQEventDispatcher, qui ne fonctionne pas avec les flux de production transitoires.

Dans les cas où vous ne pouvez pas utiliser le flux de production transitoire, vous devez exécuter la purge des flux de production régulièrement pour supprimer les flux archivés de DAM. Cela permet de conserver les performances du système. Pour configurer la purge des flux de production, ajoutez une nouvelle configuration Adobe Granite Workflow Purge à la console OSGi. Configurez et programmez-la dans votre fenêtre de maintenance hebdomadaire.

Remarque :

Le basculement du flux de mise à jour de DAM vers un flux de production transitoire désactive l’état des actifs dans le navigateur de ressources. Veuillez également consulter le Guide d’optimisation des performances des actifs.

  1. Accédez à /miscadmin dans l'instance AEM à configurer (par exemple, http://<Serveur>:<Port>/miscadmin).

  2. Dans l'arborescence de navigation, développez Outils > Flux de travaux > Modèles > dam.

  3. Double-cliquez sur DAM Update Asset.

  4. Sur le panneau d'outils flottants, accédez à l'onglet Page, puis cliquez sur Propriétés de la page.

  5. Cochez la case Transient Workflow et cliquez sur OK.

Ajustement des files d’attente de travaux

Le téléchargement en masse de fichiers volumineux est généralement un processus très gourmand en ressources. Par défaut, le nombre de threads simultanés par file d’attente est égal au nombre de cœurs du processeur. De ce fait, ce paramètre de valeur peut entraîner un impact global sur les performances et une consommation de tas Java élevée.

Adobe recommande de ne pas dépasser 50% de la capacité des cœurs du processeur. Pour ajuster cette valeur, accédez à :

http://<host>:<port>/system/console/configMgr/org.apache.sling.event.jobs.QueueConfiguration

Définissez queue.maxparallel sur une valeur représentant 50% de la capacité des cœurs du processeur du serveur qui héberge votre instance AEM. Par exemple, pour 8 cœurs de processeur, définissez la valeur sur 4.

Réglage du référentiel Oak

Assurez-vous d’avoir la dernière version de Oak installée pour votre instance AEM 6. Vérifiez la page des correctifs recommandés ci-dessus.

Optimisations moteur de requête / index Oak

  1. Installation des index recommandés (uniquement pour AEM 6.0)

    Avec les récentes améliorations apportées à Oak et à QueryBuilder, il est nécessaire de définir de nouveaux index Oak afin de garantir des performances optimales au système. Pour plus d'informations sur l'indexation Oak, voir la page associée à Apache Jackrabbit Oak.

    Vous trouverez ci-dessous des exemples de packages contenant ces nouvelles définitions d’index. Un package de définition d’index AEM 6.0 consolidé (NPR-6340) est également disponible sur demande auprès du service clientèle d'AEM.

    * damLuceneProperty.zip
    Définition d'index recommandée pour de meilleures performances de recherche d'interface utilisateur DAM classique (mise à jour le 13.03.2015)

    * productsIndex.zip
    Définitions d'indexation recommandées pour une meilleure recherche des produits Content Finder

    Remarque: pour AEM 6.1, les définitions d’index consolidées 6.0 sont disponibles, sauf pourrep:Token. Par conséquent, ce qui suit est nécessaire :

    • Ajoutez la valeur rep:Token à la propriété declaringNodeTypes du nœud /oak:index/nodetype.
    • Pour le même noeud, définissez la valeur de la propriété reindex en vrai.
    • Cliquez sur Enregistrer pour réindexer.
  2. Créez des index oak personnalisés pour toutes les requêtes de recherche fréquemment utilisées.

    • Pour plus d'informations sur la façon d'analyser les requêtes lentes, veuiller consulter cet article.
    • Créez les index personnalisés sous leoak:index nœud 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[]) pour restreindre l’index uniquement à certains chemins de contenu. Vous pouvez ensuite limiter les recherches applicables à ces chemins d’accès inclus dans l’index.
  3. Paramètres JVM

    Ajoutez ces paramètres JVM dans le script de démarrage AEM pour empêcher les requêtes expansives de surcharger les systèmes.

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

    L'option suivante peut également améliorer les performances, mais modifie la signification de l'appel de la taille du résultat. Particulièrement, seules les restrictions de requête faisant partie de l’index utilisé sont prises en compte lors du calcul de la taille. En outre, les listes ACL ne sont pas appliquées aux résultats. Par conséquent, les nœuds qui ne sont pas visibles à la session actuelle seront toujours inclus dans le décompte renvoyé. De ce fait, le nombre renvoyé peut être supérieur au nombre réel de résultats et le nombre exact ne peut être déterminé que par l’itération des résultats :

    • -Doak.fastQuerySize = true (voir aussi la taille du résultat dans Documentation Oak)
  4. Configuration de l’index Lucene

    Ouvrir system/console/configMgr/org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProviderServiceand

    • Activer CopyOnRead (activé par défaut depuis AEM 6.2)
    • Activer CopyOnWrite (activé par défaut depuis AEM 6.2)
    • Activer Récupérer des fichiers d'index (activé par défaut depuis AEM 6.2)

    Voir http://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, set a multivalue string property (String[])named excludedPaths avec ces valeurs /var, /etc/workflow/instances, /etc/replication.

  5. Entrepôt de données

    Si vous utilisez des fichiers AEM ou disposez d’une application AEM qui utilise des fichiers binaires, Adobe recommande d’utiliser un fichier externe.banque de données. L’utilisation d’une source de données externe garantit des performances optimales.  Voir documentationpour des instructions détaillées

    Lors de l’utilisation d’un FileDataStore, ajustez cacheSizeInMB sur un pourcentage de votre tas disponible. Une valeur conservatrice est de 2% du tas maximum.  Par exemple, pour un tas de 8 Go :

    maxCachedBinarySize=1048576
    cacheSizeInMB=164

    Notez que maxCachedBinarySize est réglé à 1 Mo (1048576). De ce fait, il ne met en cache que les fichiers dont la taille maximale est de 1 Mo.  L’ajustement de ce paramètre sur une valeur plus petite peut également être logique.

    Lorsque vous utilisez un grand nombre de binaires, vous souhaitez optimiser les performances. Par conséquent, Adobe recommande qu’un fichier externe soitbanque de donnéesutilisé à la place du nœud par défaut. De plus, Adobe recommande de définir les paramètres suivants :

    • maxCachedBinarySize=10485760
    • cacheSizeInMB=4096

Remarque :

Le paramètre cacheSizeInMB peut provoquer un manque 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 qu'AEM et votre application utilisent un segment de mémoire combiné de 4 Go, il est judicieux de définir cacheSizeInMB sur 82 au lieu de 164. Une plage de 2 à 10 % de la mémoire max. est une configuration prudente. Cependant, Adobe vous recommande de valider les changements de paramètre avec le test de chargement tout en gérant l’utilisation de la mémoire.

Ajustement de stockage Mongo

  1. Taille du cache MongoBlobStore: leblobstoreest utilisé pour stocker et lire des objets binaires volumineux. En interne, le magasin avec cache est implémenté, ce qui divise laLes fichiers binaires en :En blocs de taille relativement petite (données ou 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 un cache d'une taille fixée à 16 Mo.  Pour les déploiements où davantage de RAM est disponible et le stockage de blob est fréquemment accessible (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 d’une utilisation externe.blobstore.

    • Vous pouvez configurer la taille du cache (Mo) par le paramètre blobCacheSize sur DocumentNodeStoreService.
      Par exemple :
        blobCacheSize=1024.
  2. Taille du Cache de document : pour optimiser les performances des nœuds de lecture de MongoDB, vous devez définir la taille des caches de DocumentNodeStore.  La taille par défaut du cache est fixée à 256 Mo, qui est répartie entre les différents caches utilisés dans DocumentNodeStore. Consulter 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éfinir toutes les configurations de cache suivantes danscrx-quickstart/install/org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreService.configand et ensuite, charger le test avec différentes valeurs pour voir la configuration optimale de votre environnement. 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 totalisent 95%.  Les 5% restants du cache sont donnés à documentCache.
      documentCache = cache -nodeCache- childrenCache - diffCache - docChildrenCache
    • Lors de la distribution des pourcentages de cache, assurez-vous que le cache restant pour documentCache n'est pas très volumineux. C'est-à-dire, le garder à ~500 mo max ou moins; un grande documentCache peut entraîner une augmentation du temps nécessaire pour effectuer l'invalidation du cache.
  3. 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 y a un nouveau cache: prevDocCache.  Vous pouvez configurer ce cache à l’aide du paramètre prevDocCachePercentage.Par défautest 4.
    • LedocumentCache utilise le reste du cache MB (paramètre cache moins la taille de tous les autres caches):
        documentCache = cache -nodeCache- childrenCache - diffCache - docChildrenCache - prevDocCache
  4. Indice composé (AEM 6.0 avec Oak 1.0.x et AEM 6.1 avec Oak 1.2.x uniquement)

    • Créez un index transparent en arrière-plan. Si possible, effectuez cette opération durant les heures creuses. Il est conseillé d’arrêter les occurrences de AEM lorsqu’il est en cours d’exécution afin d’accélérer l’exécution. Utilisez la commande suivante :
        nohup mongo localhost:27017/aem-author --eval "db.nodes.createIndex( {_modified:1, _id:1}, { background: true } )" &
    • Ajoutez ce paramètre JVM au script de démarrage d'AEM :
        -Doak.mongo.disableIndexHint=true
  5. Mettre en œuvre la liste de contrôle de la production de MongoDB
    http://docs.mongodb.org/manual/administration/production-checklist/ - selon l’appui de Mongo DB, beaucoup des articlespossèdentun impact important sur les performances. Pour toute question, contactez le support MongoDB directement.

  6. Performance de lecture : ajoutez ce paramètre de chaîne de requête à votre URL de base de données Mongo sur chaque nœud AEM :readPreference=secondaryPreferred
    Ce paramètre indique au système de faire des lectures à partir du secondaire, ce qui donne des performances de lecture supplémentaires.

  7. Augmentez le pool de fils pour l’observation Oak : ouvrir /system/console/configMgr/org.apache.sling.commons.threads.impl.DefaultThreadPool.factory
    Définissez le nom sur oak-observation et la taille minimale et maximale du pool sur 20.

  8. Augmentez la longueur de la file 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 dans le fichier /crx-­‐quickstart/install.

  9. Évitez les requêtes longues : Définissez la propriété système dans les paramètres JVM : -Doak.mongo.maxQueryTimeMS=60000 pour éviter que les requêtes ne dépassent 1 minute.

Stockage Tar

Les micro noyaux n’appellent pas directement les fichiers mappés en mémoire. Toutefois, JDK utilise des fichiers mappés dans la mémoire pour une lecture efficace. Certains systèmes d'exploitation Windows 64 bits pourraient ne pas nettoyer les fichiers mappés dans la mémoire et consommer toute la mémoire du système d'exploitation natif. Installer les correctifs liés à la performance depuismicrosoft(consulter KB 2731284) et Oracle.

Compactage TarMK :

Pour AEM 6.0, 6.1 et 6.2, Adobe vous recommande d'utiliser un moyen de compactage hors ligne, en utilisant l'outil oak-run comme décrit ici : http://docs.adobe.com/docs/en/aem/6-0/deploy/upgrade/microkernels-in-aem-6-0.html#Maintaining the Repository.

Depuis la version AEM 6.3, le compactage en ligne (également connu sous le nom de nettoyage de révision en ligne) est accessible par défaut. Consultez cette page pour plus d'informations.

Prochaines étapes

Pour plus d’informations sur les problèmes de performances de AEM :

  1. - Surveillez votre environnement AEM pour identifier les goulots d’étranglement potentiels

    - Vérifiez les problèmes AEM critiques communs et les recommandations associées

    - Exploitez les meilleures pratiques de dépannage des performances

  2. Participez à la discussion sur les forums Astuces et astuces d'optimisation des performances AEM 6

  3. Obtenir une assistance officielle

    1. Collectez les données suivantes :
      1. Sortie du profileur
      2. Décharges de fil
      3. Tous les fichiers journaux
    2. Contactez le Service Client AEM

Ce produit est distribué sous licence Creative Commons Attribution - Pas d’utilisation commerciale - Partage à l’identique 3.0 non transposé  Les publications Twitter™ et Facebook ne sont pas couvertes par les dispositions Creative Commons.

Mentions légales   |   Politique de confidentialité en ligne