Instructions de performance

Cet page fournit des directives générales sur l’optimisation de la performance de votre déploiement AEM. Si vous n’êtes pas familier avec AEM, veuillez étudier les pages suivantes avant de commencer à lire les directives en matière de performance :

• Concepts de base d’AEM
• Présentation du stockage dans AEM 
• Déploiements recommandés
• Exigences techniques

Les options de déploiement disponibles pour l’AEM (faites défiler jusqu’à la vue de toutes les options) sont illustrées ci-dessous :

AEM Produit	Topologie	Système d’exploitation	Serveur d’applications	JRE	Sécurité	Micronoyau	Banque de données	Indexation	Serveur web	Navigateur	Marketing Cloud
Sites	Non-HA	Windows	CQSE	Oracle	LDAP	Tar	Segment	Propriété	Apache	Edge	Cible
Assets	Publish-HA	Solaris	WebLo gic	IBM	SAML	MongoDB	File	Lucene	IIS	IE	Analyses
Communautés	Author-CS	Red Hat	WebSphere	hp	Oauth	RDB/Oracle	S3/Azure	Solr	iPlanet	Firefox	Campagne
Formulaires	Déchargement d’auteur	HP-UX	Tomcat			RDB/DB2	MongoDB			Chrome	Social
Mobile	Cluster d’auteur	IBM AIX	JBoss			RDB/MySQL	RDBMS			Safari	Public
Multi-site	ASRP	SUSE				RDB/SQLServer					Ressources
Commerce	MSRP	Apple OS									Activation
Dynamic Media	JSRP										Mobile
Brand Portal	J2E
AoD
LiveFyre
Screens
Sécurité des documents
Gestion des processus
application de bureau

Quand utiliser les conseils de performance ?

Utilisez les conseils de performance dans les situations suivantes :

• Le premier déploiement : lorsque vous prévoyez de déployer AEM Sites ou AEM Assets pour la première fois, il est important de comprendre les options dont vous disposez pour configurer le micronoyau, l’entrepôt·de nœuds et l’entrepôt de données (par rapport aux paramètres par défaut). Par exemple, vous pouvez modifier les paramètres par défaut de l’entrepôt de données pour TarMK vers un entrepôt de données de fichiers.
• Mise à niveau vers une nouvelle version : lorsque vous effectuez une mise à niveau vers une nouvelle version, il est important de comprendre les différences en terme de performance par rapport à l’environnement d’exécution. Cela s’applique par exemple à une mise à niveau d’AEM 6.1 à 6.2, ou d’AEM 6.0 CRX2 à 6.2 OAK.
• Le délai de réponse est lent : lorsque l’architecture Nodestore sélectionnée ne répond pas à vos besoins, il est important de comprendre les différences de performance par rapport à d’autres options de topologie. Par exemple, le déploiement de TarMK au lieu de MongoMK ou l’utilisation d’un entrepôt de données de fichiers plutôt qu’un entrepôt de données partagé par Amazon S3 ou Microsoft Azure.
• Ajouter plus d’auteurs : lorsque la topologie TarMK ne répond plus à vos besoins de performance et une fois que de la taille du nœud d’auteur a atteint sa capacité maximale, il est important de comprendre les différences de performance par rapport à l’utilisation de MongoMK avec au mois trois nœuds d’auteur. Par exemple, le déploiement de MongoMK au lieu de TarMK.
• Ajouter plus de contenu : lorsque l’architecture recommandée d’entrepôt de données ne répond pas à vos besoins, il est important de comprendre les différences de performance par rapport à d’autres options d’entrepôt de données. Exemple : l’utilisation de l’entrepôt de données Amazon S3 ou Microsoft Azure au lieu d’un entrepôt de données de fichiers.

Présentation

Ce chapitre offre un aperçu général de l’architecture d’AEM et de ses composants les plus importants. Il fournit également des conseils de développement et décrit les scénarios dans les tests de comparaison entre TarMK et MongoMK.

La plateforme AEM

La plateforme AEM est constituée des composants suivants :

Pour plus d’informations sur la plateforme AEM, voir Ce qui est AEM.

L’architecture d’AEM

Le déploiement d’AEM repose sur trois composants clés. L’instance d’auteur utilisée par les rédacteurs, éditeurs et les approbateurs de contenu pour créer et réviser le contenu. Lorsque le contenu est approuvé, il est publié sur un type d’instance secondaire nommée instance de publication, à partir de laquelle il est consulté par les utilisateurs finaux. Le troisième bloc de construction est le Répartiteur, module qui gère la mise en cache et le filtrage des URL et qui est installé sur le serveur Web. Pour plus d’informations sur l’architecture d’AEM, voir Scénarios de déploiement classiques.

Micronoyaux

Les micronoyaux servent de gestionnaires de persistence dans AEM. Il existe trois types de micro-noyaux utilisés avec les AEM : TarMK, MongoDB et la base de données relationnelle (sous prise en charge restreinte). Le choix d’un exemple correspondant à vos besoins dépend de la finalité de l’instance et du type de déploiement envisagé. Pour plus d’informations sur les micro-noyaux, voir la page Déploiements recommandés.

Entrepôt de nœuds

Dans AEM, des données binaires peuvent être stockées indépendamment des nœuds de contenu. L’emplacement où les données binaires sont stockées est appelé​entrepôt de données, tandis que l’emplacement des nœuds et propriétés de contenu est appelé​entrepôt de nœuds(nodestore).

Entrepôt de données

Lorsque vous traitez un grand nombre de fichiers binaires, il est recommandé d’utiliser un entrepôt de données externe au lieu de l’entrepôt de nœuds par défaut pour optimiser la performance. Par exemple, si votre projet nécessite un grand nombre de ressources multimédias, leur stockage dans l’entrepôt de données Fichiers ou Azure/S3 rendra leur accès plus rapide que leur stockage direct dans une base de données MongoDB.

Pour plus d'informations sur les options de configuration disponibles, voir Configuration de Noeuds et de Stockages de données.

Recherche

Les fournisseurs d’index personnalisés utilisés avec AEM sont répertoriés dans cette section. Pour en savoir plus sur l’indexation, voir Requêtes en chêne et Indexation.

Conseils de développement

Le développement dans AEM doit être axé sur les performances et l’évolutivité. Ci-dessous figurent un certain nombre de bonnes pratiques que vous pouvez suivre :

À FAIRE

• Séparez la présentation de la logique et du contenu
• Utilisez les API (ex. : Sling) et outils (ex. : réplication ) d’AEM existants
• Développez dans le cadre du contenu réel
• Développez pour une capacité de mise en cache optimale
• Minimisez le nombre d’enregistrements (ex. : à l’aide de workflow transitoires)
• Assurez-vous que toutes les points de terminaison HTTP sont en RESTful
• Limitez la portée de l’observation JCR
• Prenez soin du thread asynchrone

À NE PAS FAIRE

• N’utilisez pas les API JCR directement, si possible

• Ne modifiez pas /libs, mais plutôt les incrustations d’utilisation

• N’utilisez pas les requêtes dans la mesure du possible

• N’utilisez pas les liaisons Sling pour obtenir des services OSGi en code Javascript, mais utilisez plutôt :

  • @Reference dans un composant DS
  • @Inject dans un modèle Sling
  • sling.getService() dans une classe d’utilisation Sightly
  • sling.getService() dans un JSP
  • un ServiceTracker
  • accès direct au registre de service OSGi

Pour plus de détails sur le développement dans AEM, lisez Développement - Principes de base. Pour connaître d’autres meilleures pratiques, reportez-vous à la section Meilleures pratiques de développement.

Scénarios de référence

Les scénarios de test détaillés ci-dessous sont utilisés pour les sections de comparaison de TarMK, MongoMk et TarMK avec les chapitres MongoMk. Pour identifier le scénario qui a été utilisé pour un test comparatif particulier, consultez le champ de scénario du tableau Caractéristiques techniques.

Scénario de produit unique

AEM Assets:

• Interactions utilisateur : Parcourir les ressources / Rechercher les ressources / Télécharger les ressources / Lire les métadonnées des ressources / Mettre à jour les métadonnées des ressources / Transférer la ressource / Exécuter le workflow Transférer la ressource
• Mode d’exécution : utilisateurs simultanés, une interaction par utilisateur

Scénario de produits variés

AEM Sites + AEM Assets :

• Interactions utilisateur de Sites : Lire l’article / Lire la page / Créer un paragraphe / Éditer un paragraphe / Activer la page de contenu / Rechercher un auteur
• Interactions utilisateur d’Assets : Parcourir les ressources / Rechercher les ressources / Télécharger les ressources / Lire les métadonnées des ressources / Mettre à jour les métadonnées des ressources / Transférer la ressource / Exécuter le workflow Transférer la ressource
• Mode d’exécution : utilisateurs simultanés, interactions variées par utilisateur

Scénario de cas d’utilisation vertical

Média:

• Lire l’article (27,4 %), lire la page (10,9 %), créer une session (2,6 %), activer la page de contenu (1,7 %) créer une page de contenu (0,4 %), créer un paragraphe (4,3 %), modifier le paragraphe (0,9 %), composant d’image (0,9 %), parcourir les ressources (20 %), lire les métadonnées de la ressource (8,5 %) télécharger la ressource (4,2 %), rechercher la ressource (0,2 %), Mettre à niveau les métadonnées de la ressource (2,4 %) transférer la ressource (1,2 %), parcourir le projet (4,9 %), lire le projet (6,6 %), Projet Ajouter une ressource (1,2 %), Projet Ajouter un site (1,2 %), créer un projet (0,1 %), rechercher un auteur (0,4 %)
• Mode d’exécution : utilisateurs simultanés, interactions variées par utilisateur

TarMK

Ce chapitre offre des directives générales en matière de performance pour TarMK, spécifiant les exigences minimales d’architecture et la configuration des paramètres. Des tests comparatifs sont également fournis pour plus de précisions.

Adobe recommande TarMK comme technologie de persistance par défaut à utiliser par les utilisateurs dans tous les scénarios de déploiement, pour les instances d’auteur et de publication AEM.

Pour plus d’informations sur TarMK, voir Scénarios de déploiement et Stockage tar.

Directives d’architecture minimale pour TarMK

Pour créer une bonne performance lorsque vous utilisez TarMK, il est conseillé de commencer à partir de l’architecture suivante :

• Une instance d’auteur
• Deux instances de publication
• Deux dispatchers

Les consignes sur l’architecture pour AEM Sites et AEM Assets sont illustrées ci-dessous.

Conseils d’architecture Tar pour AEM Sites

Conseils d’architecture Tar pour AEM Assets

Directives sur les paramètres TarMK

Pour une bonne performance, nous vous conseillons de suivre les conseils relatifs aux paramètres présentés ci-dessous. Pour savoir comment modifier les paramètres, voir cette page.

Configuration	Paramètre	Valeur	Description
Files d’attente des tâches Sling	queue.maxparallel	Définissez la valeur sur la moitié du nombre de cœurs de processeur.	Par défaut, le nombre de threads simultanés par file d’attente des tâches est égal au nombre de cœurs de processeur.
File d’attente des workflows transitoires Granite	Max Parallel	Définissez la valeur sur la moitié du nombre de cœurs de processeur.
Paramètres JVM	Doak.queryLimitInMemory Doak.queryLimitReads Dupdate.limit Doak.fastQuerySize	500 000 100 000 250 000 True	Ajoutez ces paramètres JVM dans le script de démarrage AEM afin d’empêcher les requêtes coûteuses de surcharger les systèmes.
Configuration de l’index Lucene	CopyOnRead CopyOnWrite Prefetch Index Files	Activé Activé Activé	Pour plus de détails sur les paramètres disponibles, voir cette page.
Entrepôt de données = Entrepôt de données S3	maxCachedBinarySize cacheSizeInMB	1048576 (1 Mb) ou plus petit 2-10 % de la taille maximale du tas	Voir aussi Configurations de la banque de données.
Workflow Ressource de mise à jour de la gestion des actifs numériques	Transient Workflow	vérifié	Ce workflow gère la mise à jour des ressources.
Écriture différée des métadonnées de gestion des actifs numériques	Transient Workflow	vérifié	Ce workflow gère l’écriture différée XMP au format binaire d’origine et définit la date de la dernière modification dans jcr.

Comparatif des performances TarMK

Spécifications techniques

Les tests comparatifs ont été effectués selon les spécifications suivantes :

	Noeud d’auteur
Serveur	Matériel métallique nu (HP)
Système d’exploitation	RedHat Linux
UC / Coeurs	Processeur Intel® Xeon® E5-2407 à 2,40 GHz, 8 coeurs
Mémoire RAM	32 Go
Disque	Magnétique
Java	Oracle JRE version 8
Tas JVM	16 Go
Produit	AEM 6.2
Entrepôt de nœuds	TarMK
Banque de données	Fichier DS
Scénario	Produit unique : Ressources / 30 threads simultanés

Résultats de la comparaison des performances

MongoMK

La raison principale pour choisir la persistance MongoMK plutôt que TarMK est sa capacité à faire évoluer les instances horizontalement. Cela permet d’avoir au moins deux instances d’auteur actives s’exécutant à tout moment et d’utiliser MongoDB en tant que système de stockage de persistance. La nécessité d’exécuter plus d’une instance d’auteur découle en général du fait que la capacité du processeur et de la mémoire d’un serveur unique, prenant en charge toutes les activités de création simultanées, n’est plus suffisante.

Pour plus d’informations sur TarMK, voir Scénarios de déploiement et Enregistrement Mongo.

Conseils d’architecture minimale MongoMK

Pour créer une bonne performance lorsque vous utilisez MongoMK, il est conseillé de commencer à partir de l’architecture suivante :

• Trois instances d’auteur
• Deux instances de publication
• Trois instances MongoDB
• Deux dispatchers

Directives de paramètres MongoMK

Pour une bonne performance, nous vous conseillons de suivre les conseils relatifs aux paramètres présentés ci-dessous. Pour savoir comment modifier les paramètres, voir cette page.

Configuration	Paramètre	Valeur (default)	Description
Files d’attente des tâches Sling	queue.maxparallel	Définissez la valeur sur la moitié du nombre de cœurs de processeur.	Par défaut, le nombre de threads simultanés par file d’attente des tâches est égal au nombre de cœurs de processeur.
File d’attente des workflows transitoires Granite	Max Parallel	Définissez la valeur sur la moitié du nombre de cœurs de processeur.
Paramètres JVM	Doak.queryLimitInMemory Doak.queryLimitReads Dupdate.limit Doak.fastQuerySize Doak.mongo.maxQueryTimeMS	500 000 100 000 250 000 True 60 000	Ajoutez ces paramètres JVM dans le script de démarrage AEM afin d’empêcher les requêtes coûteuses de surcharger les systèmes.
Configuration de l’index Lucene	CopyOnRead CopyOnWrite Prefetch Index Files	Activé Activé Activé	Pour plus d’informations sur les paramètres disponibles, voir cette page.
Entrepôt de données = Entrepôt de données S3	maxCachedBinarySize cacheSizeInMB	1048576 (1 Mb) ou plus petit 2-10 % de la taille maximale du tas	Voir aussi Configurations de la banque de données.
DocumentNodeStoreService	cache nodeCachePercentage childrenCachePercentage diffCachePercentage docChildrenCachePercentage prevDocCachePercentage persistentCache	2048 35 (25) 20 (10) 30 (5) 10 (3) 4 (4) ./cache,size=2048,binary=0,-compact,-compress	La taille du cache par défaut est fixée à 256 Mo. Impacte le temps qu’il faut pour exécuter l’invalidation du cache.
oak-observation	thread pool length	min et max = 20 50 000

Comparaison des performances MongoMK

Spécifications techniques

Les tests comparatifs ont été effectués selon les spécifications suivantes :

	Noeud d’auteur	Noeud MongoDB
Serveur	Matériel métallique nu (HP)	Matériel métallique nu (HP)
Système d’exploitation	RedHat Linux	RedHat Linux
UC / Coeurs	Processeur Intel® Xeon® E5-2407 à 2,40 GHz, 8 coeurs	Processeur Intel® Xeon® E5-2407 à 2,40 GHz, 8 coeurs
Mémoire RAM	32 Go	32 Go
Disque	Magique - >1 000 IOPS	Magique - >1 000 IOPS
Java	Oracle JRE version 8	N/A
Tas JVM	16 Go	S/O
Produit	AEM 6.2	MongoDB 3.2 WiredTiger
Entrepôt de nœuds	MongoMK	S/O
Banque de données	Fichier DS	S/O
Scénario	Produit unique : Ressources / 30 threads simultanés	Produit unique : Ressources / 30 threads simultanés

Résultats de la comparaison des performances

Comparaison de TarMK et MongoMK

Le principe de base à ne pas oublier lorsque vous choisissez entre les deux outils est que TarMK est conçu pour des performances, tandis que MongoMK est utilisé pour son évolutivité. Adobe recommande TarMK comme technologie de persistance par défaut à utiliser par les utilisateurs dans tous les scénarios de déploiement, pour les instances d’auteur et de publication AEM.

La raison principale pour choisir la persistance MongoMK plutôt que TarMK est sa capacité à faire évoluer les instances horizontalement. Cela permet d’avoir au moins deux instances d’auteur actives s’exécutant à tout moment et d’utiliser MongoDB en tant que système de stockage de persistance. La nécessité d’exécuter plus d’une instance d’auteur découle en général du fait que la capacité du processeur et de la mémoire d’un serveur unique, prenant en charge toutes les activités de création simultanées, n’est plus suffisante.

Pour plus de détails sur la comparaison entre TarMK et MongoMK, voir Déploiements recommandés.

Directives concernant la comparaison entre TarMK et MongoMk

Avantages de TarMK

• Conçu spécifiquement pour les applications de gestion de contenu
• Les fichiers sont toujours cohérents et peuvent être sauvegardés à l’aide de n’importe quel outil de sauvegarde basé sur un fichier
• Fournit un mécanisme de basculement : voir Cold Secondaire pour plus d'informations.
• Fournit un haut niveau de performance et un stockage de données fiable avec des frais d’exploitation minimes
• Réduit le coût total de possession

Critères de sélection de MongoMK

• Nombre d’utilisateurs nommés connectés au cours de la journée : des milliers ou plus
• Nombre d’utilisateurs simultanés : des centaines ou plus.
• Volume d’assimilation de ressources par jour : des cntaines de milliers, voire plus.
• Volume de modifications de pages par jour : des centaines de milliers ou plus
• Volume de recherches par jour : des dizaines de milliers, voire plus.

Comparaison de TarMK et MongoMK

Caractéristiques techniques du scénario 1

	Noeud OAK de l’auteur	Noeud MongoDB
Serveur	Matériel métallique nu (HP)	Matériel métallique nu (HP)
Système d’exploitation	RedHat Linux	RedHat Linux
UC / Coeurs	Processeur Intel(R) Xeon(R) E5-2407 à 2,40 GHz, 8 coeurs	Processeur Intel(R) Xeon(R) E5-2407 à 2,40 GHz, 8 coeurs
Mémoire RAM	32 Go	32 Go
Disque	Magique - >1 000 IOPS	Magique - >1 000 IOPS
Java	Oracle JRE version 8	S/O
JVM Heap16 Go	16 Go	S/O
Produit	AEM 6.2	MongoDB 3.2 WiredTiger
Entrepôt de nœuds	TarMK ou MongoMK	S/O
Banque de données	Fichier DS	S/O
Scénario	Produit unique : Ressources / 30 threads simultanés par exécution

Résultats de la comparaison des performances du scénario 1

Caractéristiques techniques du scénario 2

	Noeud TarMK de l’auteur	Noeud MongoMK de l’auteur	Noeud MongoDB
Serveur	AWS c3.8xlarge	AWS c3.8xlarge	AWS c3.8xlarge
Système d’exploitation	RedHat Linux	RedHat Linux	RedHat Linux
UC / Coeurs	32	32	32
Mémoire RAM	60 Go	60 Go	60 Go
Disque	SSD - 10 000 E/S	SSD - 10 000 E/S	SSD - 10 000 E/S
Java	Oracle JRE version 8	Oracle JRE version 8	S/O
JVM Heap16 Go	30 Go	30 Go	S/O
Produit	AEM 6.2	AEM 6.2	MongoDB 3.2 WiredTiger
Entrepôt de nœuds	TarMK	MongoMK	S/O
Banque de données	Fichier DS	Fichier DS	S/O
Scénario	Cas d’utilisation vertical : Fils simultanés Media/2000

Résultats de la comparaison des performances du scénario 2

Conseils relatifs à l’évolutivité de l’architecture d’AEMִSites et AEM Assets

Résumé des conseils de performance

Les conseils répertoriés sur cette page peuvent être résumés comme suit :

• TarMK avec l’entrepôt de donnée de fichier est l’approche recommandée pour la plupart des clients :

  • Topologie minimale : une instance d’auteur, deux instances de publication, deux dispatchers
  • Activer la réplication sans binaires si l’entrepôt de donnée de fichier est partagé

• MongoMK avec entrepôt de donnée de fichier est l’approche recommandée pour une évolutivité horizontale au niveau de l’auteur :

  • Topologie minimale : trois instances d’auteur, trois instances MongoDB, deux instances de publication, deux dispatchers
  • Activer la réplication sans binaires si l’entrepôt de donnée de fichier est partagé

• L’entreprôt de nœuds doit être stocké sur le disque local, pas dans un NAS (network attached storage)

• Lors de l’utilisation de Amazon S3 :

  • La banque de données Amazon S3 est partagée entre l’auteur et de le niveau de publication
  • La réplication sans binaires doit être activée
  • Le nettoyage de la mémoire requiert une première exécution sur tous les nœuds d’auteur et de publication, puis une seconde exécution sur l’auteur

• L’index personnalisé doit être créé en plus de l’index prêt à l’emploi basé sur la plupart des recherches courantes

  • Les index Lucene doivent être utilisés pour les index personnalisés

• La personnalisation du flux de travail peut améliorer considérablement les performances, par exemple en supprimant l’étape vidéo dans le flux de travail "Mettre à jour le fichier", en désactivant les écouteurs qui ne sont pas utilisés, etc.

Pour plus d’informations, consultez également la page Déploiements recommandés.