Directives de performance performance-guidelines
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, consultez les pages suivantes avant de commencer à lire les instructions de performances :
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 when-to-use-the-performance-guidelines
Utilisez les directives de performances 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, 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 Amazon S3 ou Microsoft Azure.
- 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 d’auteur a atteint la capacité maximale disponible, il est important de comprendre les différences de performances par rapport à 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 recommandée de magasin de données ne répond pas à vos besoins, il est important de comprendre les différences de performance par rapport à d’autres options de magasin de données. Exemple : l’utilisation de l’entrepôt de données Amazon S3 ou Microsoft Azure au lieu d’un magasin de données de fichiers.
Présentation introduction
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 the-aem-platform
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 the-aem-architecture
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 micro-kernels
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’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 micronoyaux, consultez la page Déploiements recommandés.
Entrepôt de nœuds nodestore
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 data-store
Lorsque vous traitez un grand nombre de fichiers binaires, il est recommandé d’utiliser un magasin 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 le magasin 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 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 search-features
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 development-guidelines
Vous devez développer pour AEM ciblant performance et évolutivité. Vous trouverez ci-dessous un certain nombre de 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
-
N’utilisez pas directement les API JCR, si vous le pouvez
-
Ne modifiez pas /libs, mais utilisez plutôt des superpositions
-
Ne pas utiliser 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 benchmark-scenarios
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 :
- Lire la page de l’article (27,4 %), Lecture de 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 (2Lire les métadonnées de ressources (8,5 %) Télécharger une ressource (4,2 %), Rechercher une ressource (0,2 %), Mettre à jour les métadonnées de ressource (2,4 %), Charger une ressource (1,2 %), Parcourir le projet (4,9 %), Lire le projet (6,6 %), Ajouter une ressource de projet (1,2 %), Ajouter un site de projet (1,2 %), Créer un projet (0,1 %), Créer une recherche de création (0,4 %)
- Mode d'exécution : utilisateurs simultanés, interactions mixtes par utilisateur
TarMK 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 tarmk-minimum-architecture-guidelines
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 tarmk-settings-guideline
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 tarmk-performance-benchmark
Spécifications techniques technical-specifications
Les tests comparatifs ont été réalisés selon les spécifications suivantes :
Résultats du filigrane des performances performance-bechmark-results
MongoMK 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 en permanence 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 mongomk-minimum-architecture-guidelines
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 mongomk-settings-guidelines
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 mongomk-performance-benchmark
Spécifications techniques technical-specifications-1
Les tests comparatifs ont été réalisés selon les spécifications suivantes :
Résultats de l’évaluation des performances performance-benchmark-results
Comparaison de TarMK et MongoMK tarmk-vs-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 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 en permanence 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 tarmk-vs-mongomk-guidelines
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 tarmk-vs-mongomk-benchmarks
Spécifications techniques du scénario 1 scenario-technical-specifications
Résultats de la comparaison des performances du scénario 1 scenario-performance-benchmark-results
Spécifications techniques du scénario 2 scenario-technical-specifications-1
Résultats de la comparaison des performances du scénario 2 scenario-performance-benchmark-results-1
Conseils relatifs à l’évolutivité de l’architecture d’AEM ִSites et d’AEM Assets architecture-scalability-guidelines-for-aem-sites-and-assets
Résumé des directives de performance summary-of-performance-guidelines
Les instructions présentées sur cette page peuvent être résumées comme suit :
-
TarMK avec entrepôt de données de fichier est l’architecture recommandée à 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 est l’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 doit être 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 sensiblement les performances, par exemple, la suppression d’une étape vidéo dans le flux « Ressource de mise à jour », la désactivation de listeners qui ne sont pas utilisés, etc.
Pour plus d’informations, consultez également la page Déploiements recommandés.