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 :

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.

Comparatif des performances TarMK

Spécifications techniques

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

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.

Comparaison des performances MongoMK

Spécifications techniques

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

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

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

Caractéristiques 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 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.