Directives de performance

Cet page fournit des directives générales sur l’optimisation de la performance de votre déploiement AEM. Si vous êtes un nouvel AEM, passez en revue les pages suivantes avant de commencer à lire les instructions de performances :

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

Les options de déploiement disponibles dans AEM sont illustrées ci-dessous (faites défiler l’écran pour afficher toutes les options) :

Quand utiliser les directives de performances

Suivez les instructions relatives aux performances dans les cas suivants :

• Premier déploiement: Lorsque vous envisagez de déployer AEM Sites ou Assets pour la première fois, il est important de comprendre les options disponibles. Surtout lors de la configuration du micronoyau, de l’entrepôt de noeuds et de l’entrepôt de données (par rapport aux paramètres par défaut). Par exemple, modifiez les paramètres par défaut de l’entrepôt de données pour TarMK en entrepôt de données de fichiers.
• Mise à niveau vers une nouvelle version: Lors de la mise à niveau vers une nouvelle version, il est important de comprendre les différences de performances par rapport à l’environnement en cours d’exécution. Par exemple, la mise à niveau d’AEM 6.1 vers 6.2 ou d’AEM 6.0 CRX2 vers 6.2 OAK.
• Le temps 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 performances par rapport aux 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 au lieu d’un entrepôt de données Azure Amazon S3 ou Microsoft®.
• Ajout d’autres auteurs: Lorsque la topologie TarMK recommandée ne répond pas aux exigences de performances et que la mise à niveau du noeud Auteur a atteint la capacité maximale disponible, comprenez les différences de performances. Comparez à l’utilisation de MongoMK avec trois noeuds d’auteur ou plus. Par exemple, le déploiement de MongoMK au lieu de TarMK.
• Ajouter plus de contenu: Lorsque l’architecture de l’entrepôt de données recommandée ne répond pas à vos besoins, il est important de comprendre les différences de performances par rapport aux autres options de l’entrepôt de données. Exemple : en utilisant Amazon S3 ou Microsoft® Azure Data Store au lieu d’un entrepôt de données de fichiers.

Présentation

Ce chapitre donne un aperçu général de l'architecture AEM et de ses composants les plus importants. Il fournit également des directives de développement et décrit les scénarios de test utilisés dans les tests de référence TarMK et MongoMK.

La plateforme AEM

La plateforme AEM comprend les composants suivants :

Pour plus d’informations sur la plateforme AEM, reportez-vous à la section Qu’est-ce qu’AEM ?.

L'architecture AEM

Un déploiement AEM comporte trois blocs de création importants. Le Instance de création qui est utilisé par les auteurs de contenu, les éditeurs et les approbateurs pour créer et réviser du contenu. Lorsque le contenu est validé, il est publié sur un type de seconde instance appelé Instance de publication à partir de laquelle les utilisateurs finaux y accèdent. Le troisième composant clé est le Dispatcher, qui est un module chargé de la mise en mémoire cache et du filtrage des URL. Il est installé sur le serveur web. Pour plus d’informations sur l’architecture d’AEM, consultez les Scénarios de déploiement classiques.

Noyaux micro

Les micronoyaux agissent comme des gestionnaires de persistance dans AEM. Il existe trois types de micronoyaux utilisés par AEM : TarMK, MongoDB et la base de données relationnelle (prise en charge limitée). Le choix d’une instance en fonction de vos besoins dépend de l’objectif de votre instance et du type de déploiement que vous envisagez. Pour plus d’informations sur les micronoyaux, consultez la page Déploiements recommandés.

Entrepôt de nœuds

Dans AEM, les données binaires peuvent être stockées indépendamment des noeuds de contenu. L’emplacement de stockage des données binaires est désigné sous le nom de Entrepôt de données, tandis que l’emplacement des noeuds de contenu et des propriétés est appelé Magasin de noeuds.

Magasin 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 des entrepôts de noeuds par défaut afin d’optimiser les performances. Par exemple, si votre projet nécessite de nombreuses ressources multimédias, les stocker sous le File ou Azure/S3 Data Store permet d’y accéder plus rapidement que de les stocker directement dans une MongoDB.

Pour plus de détails sur les options de configuration disponibles, consultez la section Configuration d’entrepôts de nœuds et de magasins de données.

Rechercher

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

Conseils de développement

Développer pour AEM visant performance et évolutivité. Vous trouverez ci-dessous les bonnes pratiques que vous pouvez suivre :

DO

• Séparation de la présentation, de la logique et du contenu
• Utilisez les API AEM existantes (par exemple : Sling) et les outils (par exemple : Réplication)
• Développer dans le contexte du contenu réel
• Développer pour une mise en cache optimale
• Réduisez le nombre d’enregistrements (par exemple : en utilisant des workflows transitoires)
• Assurez-vous que tous les points de terminaison HTTP sont RESTful
• Limitation de la portée de l’observation JCR
• Gardez à l’esprit les threads asynchrones

NE PAS FAIRE

• Si vous pouvez le faire, n’utilisez pas directement les API JCR.

• Ne modifiez pas /libs, mais utilisez plutôt des superpositions.

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

• N’utilisez pas de liaisons Sling pour obtenir des services OSGi dans du code Java™, 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
  • a ServiceTracker
  • accès direct au registre du service OSGi

Pour plus d’informations sur le développement sur AEM, consultez Développement - Principes de base. Pour consulter d’autres bonnes pratiques, voir Meilleures pratiques de développement.

Scénarios de test

Les scénarios de test présentés ci-dessous sont utilisés pour les sections de référence des chapitres TarMK, MongoMk et TarMK et 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 de l’utilisateur : Parcourir les ressources / Rechercher les ressources / Télécharger la ressource / Lire les métadonnées de la ressource / Mettre à jour les métadonnées de la ressource / Télécharger la ressource / Exécuter le workflow Télécharger la ressource
• Mode d'exécution : utilisateurs simultanés, une seule interaction par utilisateur

Scénario de produits mixtes

AEM Sites + AEM Assets :

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

Scénario de cas d’utilisation vertical

Média :

• Read Article Page (27.4%), Read Page (10.9%), Create Session (2.6%), Activate Content Page (1.7%), Create Content Page (0.4%), Create Paragraph (4.3%), Edit Paragraph (0.9%), Image Component (0.9%), Browse Assets (20%), Read Asset Metadata (8.5%), Download Asset (4.2%), Search Asset (0.2%), Update Asset Metadata (2.4%), Upload Asset (1.2%), Browse Project (4.9%), Read Project (6.6%), Project Add Asset (1.2%), Project Add Site (1.2%), Create Project (0.1%), Author Search (0.4%)
• Mode d'exécution : utilisateurs simultanés, interactions mixtes par utilisateur

TarMK

Ce chapitre donne des instructions générales de performances pour TarMK spécifiant les exigences minimales d’architecture et la configuration des paramètres. Des tests d’évaluation sont également fournis pour une clarification ultérieure.

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

Pour plus d’informations sur TarMK, consultez les Scénarios de déploiement et la section Stockage Tar.

Conseils d’architecture minimale TarMK

Pour obtenir de bonnes performances lors de l’utilisation de TarMK, vous devez commencer à partir de l’architecture suivante :

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

Vous trouverez, dans l’exemple ci-dessous, les directives d’architecture pour AEM sites et AEM Assets.

Consignes d’architecture Tar pour AEM Sites

Conseils d’architecture Tar pour AEM Assets

Guide des paramètres TarMK

Pour de bonnes performances, vous devez suivre les instructions de paramètres présentées ci-dessous. Pour obtenir des instructions sur la modification des paramètres, reportez-vous à cette page.

Évaluation des performances de TarMK

Spécifications techniques

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

Résultats de l’évaluation des performances

MongoMK

La Principale raison pour choisir le serveur principal de persistance MongoMK plutôt que TarMK est de mettre les instances à l’échelle horizontale. Cela signifie que deux instances d’auteur ou plus principales s’exécutent toujours et utilisent MongoDB comme système de stockage de persistance. La nécessité d’exécuter plusieurs instances de création découle généralement du fait que la capacité du processeur et de la mémoire d’un seul serveur, prenant en charge toutes les activités de création simultanées, n’est plus durable.

Pour plus d’informations sur TarMK, consultez les Scénarios de déploiement et la section Stockage Mongo.

Conseils d’architecture minimale MongoMK

Pour obtenir de bonnes performances lors de l’utilisation de MongoMK, vous devez commencer à partir de l’architecture suivante :

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

Directives relatives aux paramètres MongoMK

Pour de bonnes performances, vous devez suivre les instructions de paramètres présentées ci-dessous. Pour obtenir des instructions sur la modification des paramètres, reportez-vous à cette page.

Évaluation des performances de MongoMK

Spécifications techniques

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

Résultats de l’évaluation des performances

Comparaison de TarMK et MongoMK

La règle de base à prendre en compte lors du choix entre les deux est que TarMK est conçu pour les performances, tandis que MongoMK est utilisé pour l’é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 Principale raison pour choisir le serveur principal de persistance MongoMK plutôt que TarMK est de mettre les instances à l’échelle horizontale. Cette fonctionnalité signifie que deux instances d’auteur ou plus principales s’exécutent toujours et utilisent MongoDB comme système de stockage de persistance. La nécessité d’exécuter plusieurs instances de création découle généralement du fait que la capacité du processeur et de la mémoire d’un seul serveur, prenant en charge toutes les activités de création simultanées, n’est plus durable.

Pour plus d’informations sur TarMK et MongoMK, voir Déploiements recommandés.

Consignes TarMK et MongoMk

Avantages de TarMK

• Conçus 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 les fichiers.
• Fournit un mécanisme de basculement : consultez la section Cold Standby pour plus d’informations
• Offre des performances élevées et un stockage des données fiable avec un coût d’exploitation minimal
• Réduction du coût de possession (coût total de possession)

Critères de sélection de MongoMK

• Nombre d’utilisateurs et d’utilisatrices nommés connectés au cours de la journée : des milliers ou plus
• Nombre d’utilisateurs et d’utilisatrices simultanés : des centaines ou plus
• Volume d’ingestions de ressources par jour : des centaines de milliers ou plus
• Volume de modifications de page par jour : par centaines de milliers ou plus
• Volume de recherches par jour : des dizaines de milliers ou plus

Comparaison de TarMK et de MongoMK

Spécifications techniques du scénario 1

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

Spécifications techniques du scénario 2

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 directives de performance

Les instructions présentées sur cette page peuvent être résumées comme suit :

• TarMK avec entrepôt de données de fichier - L’architecture recommandée pour la plupart des clients :

  • Topologie minimale : une instance d’auteur, deux instances de publication, deux instances de Dispatcher
  • La réplication sans binaire est activée si l’entrepôt de données de fichier est partagé.

• MongoMK avec entrepôt de données de fichier - Architecture recommandée pour l’évolutivité horizontale du niveau Auteur :

  • Topologie minimale : trois instances d’auteur, trois instances MongoDB, deux instances de publication, deux instances de Dispatcher
  • La réplication sans binaire est activée si l’entrepôt de données de fichier est partagé.

• Nodestore - Stocké sur le disque local, et non sur un NAS (network Attachment Storage)

• Lorsque vous utilisez Amazon S3 :

  • La banque de données Amazon S3 est partagée entre les niveaux Auteur et Publication.
  • La réplication sans binaire doit être activée.
  • Le nettoyage de la mémoire d’entrepôt de données nécessite une première exécution sur tous les noeuds 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. - Selon les recherches les plus courantes

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

• La personnalisation du workflow peut améliorer considérablement les performances - Supprimez l’étape vidéo dans le workflow "Mettre à jour la ressource", en désactivant les écouteurs qui ne sont pas utilisés, etc.

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

Ressources Business.Adobe.com

Multichannel Communication Auto Text Summarization Personalized Experiences Mobile Forms Dynamic Media Headless Cms