Conseils d'optimisation des performances pour AEM 5.x

Problème

Les performances de l'instance CQ5 sont médiocres.

Cause

Les problèmes de performance dans CQ5 peuvent être dus à beaucoup de choses en combinaison. La cause la plus courante est due au code d'application. Cependant, vous pouvez prendre certaines mesures dans la configuration CQ5 pour améliorer les performances.

Résolution

Pour améliorer les performances globales de l'instance CQ, Adobe vous recommande de procéder comme suit (sur les instances d'auteur et publication).

1. Installez les correctifs recommandés

Ceci s'applique pour AEM 5.6.1. Veuillez lire attentivement https://helpx.adobe.com/fr/experience-manager/kb/cq561-available-hotfixes.html et installer les correctifs recommandés pour vos modules, en particulier celui relatif à la performance.

2. Augmentation dans bundleCacheSize CRX

Augmentez le paramètre bundleCacheSize du CRX TarPersistenceManager en procédant comme suit :

Modifiez chacun des éléments PersistenceManager dans votre repository.xml et tous vos fichiers workspace.xml en ajoutant le paramètre suivant dans le <PersistenceManager class="com.day.crx.persistence.tar.TarPersistenceManager" /> élément:
Par exemple :

<PersistenceManager class="com.day.crx.persistence.tar.TarPersistenceManager"> <param name="bundleCacheSize" value="256" /> </PersistenceManager>

Par défaut, ce cache est fixé à 8 MB. Augmentez-le à au moins 256 MB, voire 512 Mo, en fonction de la quantité de mémoire que vous pouvez affecter à la JVM. Si vous disposez d'une machine virtuelle Java avec le paramètre Xmx défini sur 10 Go, définissez bundleCacheSize sur 1024 Mo. Si vous utilisez une JVM 32 bits sous Windows, votre paramètre Xmx est probablement inférieur à 1500 MB. Par conséquent, une valeur raisonnable pour la taille bundleCacheSize est de 128 MB. Adobe recommande de mettre à niveau vers une machine virtuelle Java 64 bits pour allouer davantage de mémoire au segment de mémoire JVM.

3. Utilisez le FineGrainedISMLocking (CRX 1.4.x uniquement)

Pour le configurer, ajoutez la classe ISMLocking suivante aux workspace.xml et repository.xml, directement après le bloc SearchIndex :

<Workspace ...> ... </SearchIndex> <ISMLocking class="org.apache.jackrabbit.core.state.FineGrainedISMLocking"/> ... </Workspace>

4. Désactivez le CQ5 AssetSynchronizationService (CQ 5.3 uniquement)

La classe AssetSynchronizationService synchronise les ressources à partir de référentiels montés (par exemple : LiveLink, Documentum). Il a été observé que, lorsqu’activé, ce service alloue régulièrement de nombreux objets qui sont nettoyés de la mémoire. Par conséquent, il a un impact sur les performances de JVM. Si vous n'utilisez pas de référentiel montés, vous pouvez désactiver ce service.

Par configuration, la période de synchronisation peut être définie à une valeur plus élevée de secondes (celle par défaut étant fixée à 300), ce qui l'empêche de facto de fonctionner.

Le module joint définit la période de synchronisation sur un an, ce qui désactive le service.

5. Définissez les paramètres resultFetchSize param de l'index de recherche CRX

Si le jeu de résultats d’une requête JCR est volumineux, le chargement de l’ensemble complet et la vérification des listes CRL sont onéreux. Pour résoudre le problème, limitez la taille de récupération à 50 par l'intermédiaire de l'élément SearchIndex du workspace.xml :

<param name="resultFetchSize" value="50"/> Par exemple :

<SearchIndex class="com.day.crx.query.lucene.LuceneHandler"> <param name="path" value="${wsp.home}/index"/> <param name="resultFetchSize" value="50"/> </SearchIndex>

6. Définition des paramètres de taille du cache de la recherche CRX

La taille du cache de la recherche peut également être définie dans l'élément SearchIndex du workspace.xml. Fixez ce paramètre à 100000 :

<param name="cacheSize" value="100000" />

Par exemple :

<SearchIndex class="com.day.crx.query.lucene.LuceneHandler"> <param name="path" value="${wsp.home}/index"/> <param name="resultFetchSize" value="50"/> <param name="cacheSize" value="100000" /> </SearchIndex>

Ce paramètre est documenté ici.

7. Désactivez le groupage CRX (CRX 1.4, 2.0, 2.1)

Lors de l'exécution d'un système avec une charge d'écriture élevée (par exemple, avec des importations massives d'actifs DAM), des gains de performance en écriture relativement faibles peuvent parfois aider à atteindre les performances requises. Dans ce cas, envisagez de désactiver le journal de groupage dans votre déploiement.

Par défaut, CRX est configuré pour s'exécuter en mode groupage. Mais s'il n'y a qu'une seule instance dans le groupe, alors il ajoute une surcharge d'E / S. Pour obtenir des performances en écriture, désactivez la mise en groupe.

Dans le fichier repository.xml, commentez la section <Cluster ...>...</Cluster>
Utilisez ensuite le script exemple pour déplacer les fichiers du référentiel du mode groupe vers le mode simple.

Avant de commencer cette procédure, contactez votre service de garde ou votre responsable de compte pour discuter de cette option. La plupart des déploiements de clients s'exécutent avec les configurations journalisées par défaut. Il est préférable de tester ce script sur une instance de test le faisant sur un système de production.

8. Désactivez l'actualisation du chercheur de contenu et le chargement automatique (instance Auteur uniquement)

Reportez-vous à cet article [2]

9. Désactivez la génération d'actifs DAM

Reportez-vous à cet article [3]

10. Limitez la taille maximale du journal dans CRX

Si les fichiers journaux CRX sous partage/journal sont trop volumineux, l’application peut connaitre des ralentissements. Reportez-vous à cet article [4] pour savoir comment limiter la taille de fichier journal et le nombre maximal de fichiers.

11. Désactivation des flux DAM à la publication (instance de publication CQ 5.3 uniquement)

Reportez-vous à cet article [5]

12. Désactiver le vérificateur de lien

Un gain de performance peut être déclenché en désactivant le vérificateur de liens (en particulier avec AEM 5.6.1). Effectuer cette opération uniquement si vous décidez de ne pas l'utiliser dans votre environnement.

La vérification des liens valide l'accessibilité des URL sur l'adresse de vos pages. Pour ce faire, il effectue une demande d'en-tête HTTP.

Si un lien est non valide sur l’auteur, le vérificateur de liens affiche une icône de chaîne rompue. Si un lien est désigné comme invalide lors de la publication, alors la balise <a href="..."> est supprimée.

Certains clients le désactivent dans leurs instances de publication pour améliorer la performance. Malgré ce gain de performance, les liens brisés affectent le référencement de votre site. Examiner soigneusement les effets avant de décider de la désactiver.

Pour obtenir des instructions sur la désactivation de cette fonction, consulter cet article [6].

13. Index du cache Tar PM

Jusqu'à CRX 2.1

L'utilisation d'un travail cron pour lire le fichier index*.tar de temps à autre peut aider à améliorer les performances, car l'index tar est mis en cache dans le cache d'E / S matérielles. Sous UNIX, vous pouvez charger l'index*.tar à l'aide de la commande "cat index*.tar > /dev/null". Faire cela chaque heure devrait aider à améliorer les performances du gestionnaire de persistance Tar lors de l'exécution de la méthode TarFile.readFully().

A partir de CRX 2.2 + hotfixpack 2.2.0.26 et supérieur

Vérifiez la taille globale des fichiers index_*.tar dans l'espace de travail crx.default, augmentez la taille maximale du segment de mémoire de cette taille et définissez le paramètre indexInMemory sur true pour la section TarPersistenceManager du fichier workspace.xml:

<PersistenceManager class="com.day.crx.persistence.tar.TarPersistenceManager">
<param name="indexInMemory" value="true" />
</PersistenceManager>

L'espace requis pour un nœud JCR est de 128 octets. Si le plus grand fichier index*.tar d'un espace de travail est de 1 Go, cela signifie qu'il y a environ 16 millions de nœuds dans cet espace de travail, car chaque nœud a besoin de 64 octets d'espace disque. Utilisation de l'option d'index en mémoire nécessite environ 2 Go d'espace de tas (le double de la taille du fichier pour calculer l'espace de tas requis car il peut y avoir deux versions par fichier d'index lors de la fusion d'index).

14. Expiration du cache LDAP

Pour améliorer les performances et réduire la latence pendant le processus d'authentification, il est bon d'augmenter l'expiration du cache LDAP, vous pouvez définir cache.expiration à 86400 (un jour) dans votre configuration LDAP.

15. Optimisez l'index lucene pour gagner de l'espace disque et de l'efficacité

Références

[1] http://wiki.apache.org/jackrabbit/Search
[2] Comment modifier l'intervalle de rafraîchissement ContentFinder
[3] Comment supprimer la génération de sous-ensembles de DAM Workflow
[4] Journal consomme trop d'espace disque
[5] Comment désactiver les flux de travail DAM sur la publication
[6] Désactivez Linkchecker
[7] Optimiser l'index lucene pour gagner de l'espace disque et de l'efficacité

S’applique à

CQ 5.x, CRX 2.x