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 :
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 |
|
|
|
|
|
|
|
|
|
|
|
Les directives de performance s’appliquent principalement à AEM Sites.
Utilisez les conseils de performance dans les situations suivantes :
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 est constituée des composants suivants :
Pour plus d’informations sur la plateforme AEM, voir Ce qui est 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.
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.
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).
Adobe recommande TarMK comme technologie de persistance par défaut à utiliser par les clients pour les instances d’auteur et de publication AEM.
La prise en charge du micronoyau de la base de données relationnelle est limitée. Contactez l’assistance clientèle d’Adobe avant d’utiliser ce type de micronoyau.
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.
Adobe recommande d’utiliser l’option de déploiement d’AEM sur Azure ou Amazon Web Services (AWS) en utilisant les services d’Adobe Managed Services, où les clients pourront bénéficier d’une équipe possédant l’expérience et les compétences de déploiement et d’opération d’AEM pour les environnements de cloud computing. Consultez notre documentation supplémentaire sur Adobe Managed Services.
Pour des recommandations sur le déploiement d’AEM sur Azure ou AWS, en dehors des Adobe Managed Services, nous vous recommandons vivement de travailler directement avec votre fournisseur cloud ou avec l’un de nos partenaires prenant en charge le déploiement d’AEM dans l’environnement de cloud de votre choix. Le partenaire ou fournisseur cloud que vous choisissez est responsable du dimensionnement, de la conception et de l’implémentation de l’architecture qu’ils vont prendre en charge pour répondre à vos besoins spécifiques en matière de performance, de chargement, d’évolutivité et de sécurité.
Pour plus de détails, voir la page exigences techniques.
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.
Pour la plupart des déploiements, Adobe conseille d’utiliser l’index Lucene. Nous vous recommandons d’utiliser Solr uniquement pour son évolutivité dans les déploiements spécialisés et plus complexes.
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
À 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 :
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.
Tous les tests comparatifs affichés sur cette page ont été réalisés dans un environnement de laboratoire.
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:
Scénario de produits variés
AEM Sites + AEM Assets :
Scénario de cas d’utilisation vertical
Média:
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.
Les directives d’architecture minimale présentées ci-dessous concernent les environnements de production et les sites ayant un trafic élevé. Il s'agit non des spécifications minimales requises pour exécuter AEM.
Pour créer une bonne performance lorsque vous utilisez TarMK, il est conseillé de commencer à partir de l’architecture suivante :
Les consignes sur l’architecture pour AEM Sites et AEM Assets sont illustrées ci-dessous.
La réplication sans binaires doit être ACTIVÉE si l’entrepôt de données du fichier est partagé.
Conseils d’architecture Tar pour AEM Sites
Conseils d’architecture Tar pour AEM Assets
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 |
|
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 |
|
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 |
|
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. |
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 |
Les chiffres présentés ci-dessous ont été normalisés en prenant 1 comme ligne de base et ne représentent pas les chiffres de débit réels.
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.
Pour créer une bonne performance lorsque vous utilisez MongoMK, il est conseillé de commencer à partir de l’architecture suivante :
Dans les environnements de production, MongoDB sera toujours utilisé comme un ensemble de réplication avec une instance principale et deux instances secondaires. Les lectures et écritures sont envoyées à l’instance principale alors que les lectures peuvent être envoyées aux instances secondaires. Si le stockage n’est pas disponible, une des instances secondaires peut être remplacée par un arbitre, mais les ensembles de réplication MongoDB doivent toujours être composés d’un nombre impair d’instances.
La réplication sans binaires doit être ACTIVÉE si l’entrepôt de données du fichier est partagé.
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 |
|
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 |
|
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 |
|
1048576 (1 Mb) ou plus petit 2-10 % de la taille maximale du tas |
Voir aussi Configurations de la banque de données. |
DocumentNodeStoreService |
|
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 |
|
min et max = 20 50 000 |
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 |
Les chiffres présentés ci-dessous ont été normalisés en prenant 1 comme ligne de base et ne représentent pas les chiffres de débit réels.
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.
Avantages de TarMK
Critères de sélection de MongoMK
Les chiffres présentés ci-dessous ont été normalisés en prenant 1 comme ligne de base et ne représentent pas les chiffres de débit réels.
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 |
|
Pour activer le même nombre d’auteurs avec MongoDB qu’avec un système TarMK, vous aurez besoin d’un cluster avec deux nœuds AEM. Un cluster MongoDB de quatre nœuds peut gérer 1,8 fois le nombre d’auteurs d’une instance TarMK. Un cluster MongoDB de huit nœuds peut gérer 2,3 fois le nombre d’auteurs d’une instance TarMK.
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 |
|
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 :
MongoMK avec entrepôt de donnée de fichier est l’approche recommandée pour une évolutivité horizontale au niveau de l’auteur :
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 :
L’index personnalisé doit être créé en plus de l’index prêt à l’emploi basé sur la plupart des recherches courantes
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.