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 débutez avec AEM, consultez les pages suivantes avant de commencer à lire les directives de performance :
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 performance when-to-use-the-performance-guidelines
Suivez les directives de performance 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 bien comprendre les options disponibles. Surtout pour la configuration du micronoyau, du magasin de nœuds et du magasin de données (par rapport aux paramètres par défaut). Vous pouvez par exemple modifier les paramètres par défaut du magasin de données pour TarMK en magasin 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 performance par rapport à l’environnement en cours d’exécution. Il s’agit par exemple de la mise à niveau d’AEM 6.1 vers 6.2 ou d’AEM 6.0 CRX2 vers 6.2 OAK.
- Temps de réponse 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 aux autres options de topologie. Il s’agit par exemple du déploiement de TarMK au lieu de MongoMK ou de l’utilisation d’un magasin de données de fichiers au lieu d’un magasin de données Amazon S3 ou Microsoft® Azure.
- Ajout d’autres auteurs et autrices : lorsque la topologie TarMK recommandée ne répond pas aux exigences de performance et que la mise à niveau du nœud d’instance de création a atteint la capacité maximale disponible, comprenez bien les différences de performance. Comparez l’utilisation de MongoMK avec trois nœuds d’instance de création 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 : utilisation du magasin de données Amazon S3 ou Microsoft® Azure au lieu d’un magasin de données de fichiers.
Présentation introduction
Ce chapitre propose une vue d’ensemble de l’architecture d’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 d’AEM the-aem-architecture
Un déploiement d’AEM comporte trois blocs de création importants. L’instance de création qui est utilisée par les personnes qui créent, éditent et approuvent du contenu pour produire et réviser du contenu. Lorsque le contenu est validé, il est publié sur un second type d’instance nommé instance de publication à partir de laquelle les personnes utilisatrices finales 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.
Micronoyaux 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’une solution adaptée à vos besoins dépend de l’objectif de votre instance et du type de déploiement que vous prévoyez. 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 nœuds de contenu. L’emplacement de stockage des données binaires est désigné sous le nom de magasin de données, tandis que l’emplacement des nœuds de contenu et des propriétés est nommé magasin de nœuds.
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 du magasin 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 de 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 de magasins de nœuds et de magasins de données.
Consultez également la page des exigences techniques.
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
Développez pour AEM et optimisez les performances et l’évolutivité. Vous trouverez ci-dessous quelques bonnes pratiques :
Bonnes pratiques
- Faites une distinction entre la présentation, la logique et le contenu.
- Utilisez les API d’AEM (Sling etc.) et les outils (la réplication, par exemple) à votre disposition.
- Développez dans le contexte du contenu réel.
- Développez avec une mise en cache optimale en ligne de mire.
- Réduisez le nombre d’enregistrements (par exemple, en utilisant des workflows transitoires).
- Assurez-vous que tous les points d’entrée HTTP sont RESTful.
- Limitez la portée de l’observation JCR.
- Gardez à l’esprit les threads asynchrones.
Mauvaises pratiques
-
N’utilisez pas directement les API JCR, si possible.
-
Ne modifiez pas les répertoires /libs, utilisez plutôt des recouvrements.
-
N’utilisez pas de requêtes dans la mesure du possible.
-
N’utilisez pas de liaisons Sling pour obtenir des services OSGi dans le 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 ;
- un ServiceTracker ;
- un accès direct au registre du service OSGi.
Pour plus d’informations sur le développement sur AEM, consultez la section Principes de base du développement. Pour consulter d’autres bonnes pratiques, rendez-vous sur Bonnes pratiques en matière de développement.
Scénarios de référence 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 contre 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 des 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 et utilisatrices simultanés, une seule interaction par personne.
Scénario de produits mixtes
AEM Sites + AEM Assets :
- Interactions utilisateur de Sites : lire une page d’article / lire une page / créer un paragraphe / modifier le paragraphe / créer une page de contenu / activer la page de contenu / créer une recherche.
- Interactions utilisateur d’Assets : parcourir les ressources / rechercher des 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 et utilisatrices simultanés, interactions mixtes par personne.
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 et utilisatrices simultanés, interactions mixtes par personne.
TarMK tarmk
Ce chapitre donne des recommandations pour tirer le meilleur parti des performances de TarMK. Vous y trouverez les exigences minimales en matière d’architecture et la configuration des paramètres. Des tests de référence sont également fournis pour plus de clarté.
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.
Recommandations sur l’architecture minimale de TarMK tarmk-minimum-architecture-guidelines
Pour obtenir de bonnes performances lors de l’utilisation de TarMK, commencez par l’architecture suivante :
- une instance de création ;
- deux instances de publication ;
- deux Dispatchers.
Vous trouverez, dans l’exemple ci-dessous, les recommandations sur l’architecture d’AEM Sites et AEM Assets.
Recommandations sur l’architecture Tar pour AEM Sites
Conseils d’architecture Tar pour AEM Assets
Paramètres TarMK recommandés tarmk-settings-guideline
Pour obtenir de bonnes performances, il est recommandé de définir les paramètres comme suit. Pour obtenir des instructions sur la modification des paramètres, Voir Optimisation des performances.
Référence 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 de l’évaluation des performances performance-benchmark-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. Ainsi, au moins deux instances de création actives fonctionnent en permanence et MongoDB est utilisé comme système de stockage de persistance. La nécessité d’exécuter plusieurs instances de création est due au 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 suffisante.
Pour plus d’informations sur TarMK, consultez les Scénarios de déploiement et la section Stockage Mongo.
Rrecommandations sur l’architecture minimale de MongoMK mongomk-minimum-architecture-guidelines
Pour tirer le meilleur parti des performances de MongoMK, commencez par l’artchitecture suivante :
- trois instances de création ;
- deux instances de publication ;
- trois instances MongoDB ;
- deux Dispatchers.
Paramètres MongoMK recommandés mongomk-settings-guidelines
Pour obtenir de bonnes performances, il est recommandé de définir les paramètres comme suit. Pour obtenir des instructions sur la modification des paramètres, voir Optimisation des performances.
Référence 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-1
Comparaison de TarMK et MongoMK tarmk-vs-mongomk
La règle de base à prendre en compte pour choisir 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 de création principales ou plus 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 suffisante.
Pour plus d’informations sur la comparaison de TarMK et MongoMK, voir Déploiements recommandés.
Consignes sur la comparaison de TarMK et MongoMk tarmk-vs-mongomk-guidelines
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 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
- Coût total de possession plus faible
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 : des centaines de milliers ou plus
- Volume de recherches par jour : des dizaines de milliers ou plus
Références concernant la comparaison de TarMK et 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 recommandations sur les performances summary-of-performance-guidelines
Consultez ci-dessous un résumé des recommandations fournies sur cette page :
-
TarMK avec magasin de données du fichier : l’architecture recommandée pour la plupart des clientes et clients :
- Topologie minimale : une instance de création, deux instances de publication, deux Dispatcher.
- La réplication sans fichiers binaires doit être activée si le magasin de données du fichier est partagé.
-
MongoMK avec magasin de données du fichier : l’architecture recommandée pour l’évolutivité horizontale au niveau de création :
- Topologie minimale : trois instances de création, trois instances MongoDB, deux instances de publication, deux Dispatcher.
- La réplication sans fichiers binaires doit être activée si le magasin de données du fichier est partagé.
-
Magasin de nœuds : stocké sur le disque local et non sur un serveur NAS (dispositif de stockage réseau).
-
Lorsque vous utilisez Amazon S3 :
- Le magasin de données Amazon S3 est partagé entre les niveaux de création et de publication.
- La réplication sans fichiers binaire doit être activée.
- La récupération de l’espace mémoire du magasin de données nécessite une première exécution sur tous les nœuds des instances de création et de publication, puis une seconde exécution sur l’instance de création.
-
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 : la suppression de l’étape vidéo dans le workflow « Ressource de mise à jour », la désactivation d’écouteurs qui ne sont pas utilisés, etc.
Pour plus d’informations, consultez également la page Déploiements recommandés.