Vous consultez actuellement l'aide de la version:

Ces consignes de dimensionnement procurent une estimation des ressources matérielles requises pour déployer un projet AEM. Les estimations de dimensionnement dépendent de l’architecture du projet, de la complexité de la solution, du trafic estimé et des exigences du projet. Ce guide vous aide à déterminer les besoins matériels pour une solution spécifique ou à trouver une estimation supérieure et inférieure pour les exigences matérielles.

Les facteurs de base à prendre en compte sont (dans cet ordre) :

  • Vitesse du réseau
    • Latence du réseau
    • Bande passante disponible
  • Vitesse de calcul
    • Efficacité de la mise en cache
    • Trafic attendu
    • Complexité des modèles, des applications et des composants
    • Auteurs simultanés
    • Complexité de l’opération de création (modification de contenu simple, déploiement MSM, etc.)
  • Performance d’E/S
    • Performance et efficacité du stockage des fichiers ou de la base de données
  • Disque dur
    • Au moins deux ou trois fois plus grand que la taille du référentiel
  • Mémoire
    • Taille du site web (nombre d’objets de contenu, de pages et d’utilisateurs)
    • Nombre d’utilisateurs/de sessions qui sont actifs en même temps

Architecture

Une configuration AEM type se compose d’un environnement de création et de publication. Ces environnements ont différentes exigences en ce qui concerne la taille du matériel sous-jacent et la configuration système. Vous trouverez des remarques sur les deux environnements dans les sections Environnement de création et Environnement de publication.

Dans une configuration de projet type, vous disposez de plusieurs environnements sur lesquels définir les phases du projet :

  • L’environnement de développement
    pour le développement de nouvelles fonctions ou pour apporter des modifications importantes. La meilleure pratique consiste à travailler dans un environnement de développement par développeur (généralement des installations locales sur leurs systèmes personnels).
  • L’environnement de test de création pour vérifier les modifications.
    Le nombre d’environnements de test varie selon les exigences du projet (qui nécessite, par exemple, un environnement distinct pour l’assurance qualité, le test de l’intégration ou le test d’acceptation utilisateur).
  • L’environnement de test de publication
    principalement pour tester les cas d’utilisation de collaboration sociale et/ou l’interaction entre l’instance de création et plusieurs instances de publication.
  • L’environnement de production de création
    pour que les auteurs modifient le contenu.
  • L’environnement de production de publication
    pour servir du contenu publié.

En outre, les environnements peuvent varier, d’un système à un serveur exécutant AEM et un serveur d’application, à un ensemble d’instances organisées en grappes multiserveur et multiprocesseur hautement évoluées. Nous vous recommandons d’utiliser un ordinateur distinct pour chaque système de production et de ne pas exécuter d’autres applications sur ces ordinateurs.

Remarques génériques concernant le dimensionnement du matériel

Les sections suivantes fournissent des instructions pour calculer les configurations matérielles requises, en prenant en compte plusieurs points. Pour les systèmes de grande taille, nous suggérons que vous réalisiez un simple jeu de tests d’évaluation des performances en interne sur une configuration de référence.

L’optimisation des performances est une tâche fondamentale qui doit être effectuée avant que toute évaluation des performances ne puisse être réalisée pour un projet spécifique. Veillez à suivre les conseils fournis dans la documentation d’optimisation des performances avant de procéder aux tests d’évaluation des performances et d’utiliser leurs résultats pour les calculs de dimensionnement du matériel.

Les exigences de dimensionnement du matériel pour les cas d’utilisation plus complexes doivent reposer sur une estimation détaillée des performances du projet. Les cas d’utilisation plus complexes qui nécessitent des ressources matérielles exceptionnelles présentent une combinaison des caractéristiques suivantes :

  • charge utile/débit de contenu élevé ;
  • usage intensif de code personnalisé, de workflows personnalisés ou de bibliothèques de logiciels tiers ;
  • intégration à des systèmes externes non pris en charge.

Disque dur/espace disque

L’espace disque requis dépend largement du volume et du type de votre application web. Les calculs doivent prendre en compte les éléments suivants :

  • le nombre et la taille des pages, des ressources et des autres entités stockées dans un référentiel, telles que les workflows, les profils, etc. ;
  • la fréquence attendue de modifications du contenu et donc de la création de versions de contenu ;
  • le volume de rendus de ressources de gestion des actifs numériques qui seront générés ;
  • la croissance générale du contenu au fil du temps.

L’espace disque est continuellement surveillé en ligne, hors ligne et lors du nettoyage des révisions. Si l’espace disque passe en dessous d’une certaine valeur, le processus est annulé. La valeur critique correspond à 25 % de l’encombrement sur le disque du référentiel ; elle n’est pas configurable. Il est recommandé de dimensionner le disque de sorte qu’il soit au moins deux ou trois fois plus large que la taille du référentiel, y compris sa croissance estimée.

Envisagez une configuration de baies redondantes composée de disques indépendants (RAID, par exemple RAID10) pour la redondance des données.

Remarque :

Le répertoire temporaire d’une instance de production doit disposer d’au moins 6 Go d’espace disponible.

Virtualisation

AEM s’exécute correctement dans les environnements virtualisés, mais certains facteurs tels que l’unité centrale ou les E/S peuvent ne pas correspondre directement au matériel physique. Nous vous recommandons de sélectionner une vitesse d’E/S accrue (en général), car il s’agit d’un facteur déterminant dans la plupart des cas. L’évaluation des performances de votre environnement est nécessaire pour obtenir une idée précise des ressources requises.

Mise en parallèle d’instances AEM

Prévention de défaillance

Un site web doté de la prévention de défaillance est déployé sur au moins deux systèmes distincts. Si un système tombe en panne, un autre système peut prendre la relève de façon à compenser la défaillance du système.

Évolutivité des ressources système

Lorsque tous les systèmes sont en cours d’exécution, une performance de calcul accrue est disponible. Cette performance supplémentaire n’est pas nécessairement linéaire par rapport au nombre de nœuds de grappes, car les relations dépendent lourdement de l’environnement technique. Voir la documentation relative aux grappes pour plus d’informations.

L’estimation du nombre de nœuds de grappes nécessaires dépend des exigences de base, ainsi que des cas d’utilisation spécifiques du projet web en question :

  • Du point de vue de la prévention de défaillance, il est nécessaire de déterminer, pour tous les environnements, l’importance de la défaillance et le temps de compensation de la défaillance en fonction du temps nécessaire pour qu’un nœud de grappes se rétablisse.
  • En ce qui concerne l’évolutivité, le nombre d’opérations d’écriture est fondamentalement le facteur le plus important. Voir Auteurs travaillant en parallèle pour l’environnement de création et Collaboration sociale pour l’environnement de publication. L’équilibrage de charge peut être établi pour les opérations qui accèdent au système uniquement afin de traiter les opérations de lecture. Voir Dispatcher pour plus d’informations.

Calculs spécifiques à l’environnement de création

Adobe a développé plusieurs tests d’évaluation des performances pour des instances de création autonomes.

  • Test d’évaluation des performances 1

    Calcule le débit d’un profil de charge lorsque les utilisateurs exécutent un simple exercice de création de pages sur une charge de base de 300 pages existantes, toutes de nature similaire. Les étapes impliquées étaient la connexion au site, la création d’une page contenant un SWF et une image/du texte, l’ajout d’un nuage de balises, puis l’activation de la page.
    • Résultat

      Le débit maximal d’un simple exercice de création de pages comme plus haut (considéré comme une transaction) est de 1 730 transactions/heure.
  • Test d’évaluation des performances 2

    Calcule le débit maximal lorsque le profil de charge comprend la création d’une page (10 %), la modification d’une page existante (80 %), ainsi que la création, puis la modification d’une page successivement (10 %). La complexité des pages reste la même que dans le profil du test d’évaluation des performances 1. La modification de base de la page est effectuée en ajoutant une image et en modifiant le contenu textuel. Là encore, l’exercice a été effectué sur une charge de base de 300 pages de même complexité, tel que défini dans le test d’évaluation des performances 1.
    • Résultat

      Le débit maximal d’un tel scénario mélangeant des opérations est de 3 252 transactions par heure.

Remarque :

Le débit ne fait pas la distinction entre les types de transactions au sein d’un profil de charge. La méthode utilisée pour mesurer le débit s’assure qu’une proportion fixe de chaque type de transaction est incluse dans la charge de travail.

Les deux tests ci-dessus indiquent que le débit varie en fonction du type d’opération. Utilisez les activités dans votre environnement comme base pour dimensionner votre système. Vous obtenez un meilleur débit avec des actions moins intensives, telles que la modification (qui est également plus courante).

Mise en cache

Dans l’environnement de création, l’efficacité de la mise en cache est en général bien plus faible, car les modifications du site web sont plus fréquentes et en raison du caractère hautement interactif et personnalisé du contenu. En utilisant le Dispatcher, vous pouvez mettre en cache des bibliothèques AEM, des scripts JavaScript, des fichiers CSS et des images de mise en page. Cela permet d’accélérer certains aspects du processus de création. La configuration du serveur web afin de définir des en-têtes supplémentaires pour la mise en cache de ces ressources dans le navigateur, réduit le nombre de requêtes HTTP et améliore ainsi la réactivité du système pour les auteurs.

Auteurs travaillant en parallèle

Dans l’environnement de création, le nombre d’auteurs qui travaillent en parallèle et la charge que leurs interactions ajoutent au système constituent les principaux facteurs de limitation. Par conséquent, nous vous recommandons de dimensionner votre système en fonction du débit partagé des données.

Pour de tels scénarios, Adobe a effectué des tests d’évaluation des performances sur une grappe à deux nœuds sans partage d’instances de création.

  • Test d’évaluation des performances 1a
    Avec une grappe sans partage active-active de deux instances de création, calcule le débit maximal avec un profil de charge où les utilisateurs exécutent un exercice simple de création de page sur une charge de base de 300 pages existantes, toutes de nature similaire.
    • Résultat
      Le débit maximal d’un simple exercice de création de page comme plus haut (considéré comme une transaction) est de 2 016 transactions/heure. Il s’agit d’une augmentation d’environ 16 % par rapport à une instance de création autonome pour la même évaluation des performances.
  • Test d’évaluation des performances 2b
    Avec une grappe sans partage active-active de deux instances de création, calcule le débit maximal lorsque le profil de charge comprend la création d’une page (10 %), la modification de pages existantes (80 %), ainsi que la création et la modification d’une page successivement (10 %). La complexité de la page reste la même que dans le profil du test d’évaluation des performances 1. La modification de base de la page est effectuée en ajoutant une image et en modifiant le contenu textuel. Là encore, l’exercice a été effectué sur une charge de base de 300 pages de même complexité, tel que défini dans le test d’évaluation des performances 1.
    • Résultat
      Le débit maximal d’un tel scénario mélangeant des opérations est de 6 288 transactions par heure. Il s’agit d’une augmentation d’environ 93 % par rapport à une instance de création autonome pour la même évaluation des performances.

Remarque :

Le débit ne fait pas la distinction entre les types de transactions au sein d’un profil de charge. La méthode utilisée pour mesurer le débit s’assure qu’une proportion fixe de chaque type de transaction est incluse dans la charge de travail.

Les deux tests ci-dessus indiquent clairement qu’AEM se dimensionne correctement pour les auteurs qui exécutent des opérations de modification de base avec AEM. En général, AEM est plus efficace pour dimensionner les opérations de lecture.

Sur un site web type, la plus grande partie de la création se produit pendant la phase de projet. Une fois le site web activé, le nombre d’auteurs travaillant en parallèle baisse généralement vers une moyenne inférieure (en mode opérationnel). 

Vous pouvez calculer le nombre d’ordinateurs (ou unités centrales) requis pour l’environnement de création comme suit :

n = nombreD’auteursEnParallèle/30

Cette formule peut servir d’orientation générale pour dimensionner les unités centrales lorsque les auteurs effectuent des opérations de base avec AEM. Elle part du principe que le système et l’application sont optimisés. Toutefois, la formule ne convient pas pour les fonctions avancées telles que MSM ou Assets (voir les sections ci-dessous).

Consultez également les commentaires supplémentaires dans Mise en parallèle et Optimisation des performances.

Recommandations matérielles

En règle générale, vous pouvez utiliser pour votre environnement de création le même matériel que celui recommandé pour votre environnement de publication. Le trafic de votre site web est normalement nettement inférieur sur les systèmes de création, mais l’efficacité du cache est également inférieure. Toutefois, le facteur fondamental est ici le nombre d’auteurs travaillant en parallèle, ainsi que le type des actions réalisées sur le système. En général, la mise en grappe AEM (de l’environnement de création) est plus efficace pour dimensionner les opérations de lecture ; en d’autres termes, une grappe AEM se dimensionne correctement avec les auteurs qui effectuent des opérations de modification de base.

Adobe a effectué les tests d’évaluation des performances à l’aide du système d’exploitation Red Hat 5.5 exécuté sur une plate-forme matérielle Hewlett-Packard ProLiant DL380 G5 avec la configuration suivante :

  • Deux unités centrales Intel Xeon Quad Core X5450 à 3 GHz
  • 8 Go de RAM
  • Gigabit Ethernet Broadcom NetXtreme II BCM5708
  • Contrôleur RAID HP Smart Array, avec une mémoire cache de 256 Mo
  • Deux disques SAS à 10 000 tr/min de 146 Go configurés en tant que jeu d’agrégats par bandes RAID0
  • Le score d’évaluation des performances de la spécification CINT2006 est de 110.

Les instances AEM fonctionnaient avec une taille de tas minimale de 256 Mo et une taille maximale de 1 024 Mo.

Calculs spécifiques à l’environnement de publication

Efficacité de la mise en mémoire cache et trafic

L’efficacité de la mise en mémoire cache est cruciale pour la vitesse du site web. Le tableau suivant indique le nombre de pages pouvant être gérées par seconde par un système AEM optimisé à l’aide d’un proxy inverse, tel que le Dispatcher :

Rapport de cache Pages/s (pic) Million de pages/jour (moyenne)
100 % 1 000-2 000 35-70
99 % 910 32
95 % 690 25
90 % 520 18
60 % 220 8
0 % 100 3,5

Attention :

Clause de non-responsabilité : les chiffres sont basés sur une configuration matérielle par défaut et peuvent varier en fonction du matériel utilisé.

Le rapport de cache est le pourcentage de pages que le Dispatcher peut renvoyer sans devoir accéder à AEM. 100 % indique que le Dispatcher répond à toutes les requêtes, 0 % signifie qu’AEM calcule chaque page.

Complexité des modèles et des applications

Si vous utilisez des modèles complexes, AEM aura besoin de plus de temps pour effectuer le rendu d’une page. Les pages extraites du cache ne sont pas affectées, mais la taille de la page est toujours pertinente en ce qui concerne le délai de réponse global. Le rendu d’une page complexe peut aisément prendre dix fois plus longtemps que le rendu d’une seule page.

Formule

À l’aide de la formule suivante, vous pouvez calculer une estimation de la complexité globale de votre solution AEM :  

complexité = complexitéDeL’application + ((1-rapportDeCache) x complexitéDuModèle)

Selon la complexité, vous pouvez déterminer le nombre de serveurs (ou de cœurs d’unité centrale) dont vous avez besoin pour l’environnement de publication comme suit :  

n = (trafic x complexité/1 000) x activations

Les variables de l’équation sont les suivantes :

trafic Trafic maximal attendu par seconde. Vous pouvez l’estimer comme le nombre de visites de pages par jour, divisé par 35 000.
complexitéDeL’application

Utilisez 1 pour une application simple, 2 pour une application complexe, ou une valeur intermédiaire :

  • 1 : un site orienté contenu et complètement anonyme
  • 1,1 : un site orienté contenu et complètement anonyme avec une personnalisation côté client/cible
  • 1,5 : un site orienté contenu avec des sections anonymes et connectées, ainsi qu’une personnalisation côté client/cible
  • 1,7 : pour un site orienté contenu avec des sections anonymes et connectées, ainsi qu’une personnalisation côté client/cible et du contenu généré par les utilisateurs
  • 2 : où le site entier requiert une connexion, avec une utilisation importante de contenu généré par les utilisateurs, ainsi qu’une variété de techniques de personnalisation
rapportDeCache Pourcentage de pages sortant du cache du Dispatcher. Utilisez 1 si toutes les pages proviennent du cache ou 0 si chaque page est calculée par AEM.
complexitéDuModèle Utilisez une valeur entre 1 et 10 afin d’indiquer la complexité de vos modèles. Des valeurs plus élevées indiquent des modèles plus complexes ; utilisez une valeur de 1 pour les sites avec une moyenne de 10 composants par page, une valeur de 5 pour une moyenne de 40 composants par page et 10 pour une moyenne de plus de 100 composants.
activations Nombre d’activations moyennes (réplication de pages et de ressources de taille moyenne de l’auteur vers le niveau de publication) par heure divisé par x, où x est le nombre d’activations effectuées sur un système sans effets secondaires sur la performance des autres tâches traitées par le système. Vous pouvez également prédéfinir une valeur initiale pessimiste comme x = 100.

Si vous possédez un site web plus complexe, vous avez également besoin de serveurs web plus puissants afin qu’AEM réponde à une requête dans un délai acceptable.  

  • Complexité inférieure à 4 :
        •    JVM AVEC 1 024 MO DE RAM*
        •    Unité centrale de performance faible à moyenne
  • Complexité entre 4 et 8 :
        •    JVM AVEC 2 048 MO DE RAM*
        •    Unité centrale de performance moyenne à élevée
  • Complexité supérieure à 8 :
        •    JVM AVEC 4 096 MO DE RAM*
        •    Unité centrale de performance élevée à très élevée

Remarque :

* Réservez suffisamment de RAM pour votre système d’exploitation en plus de la mémoire requise pour votre JVM.

Autres calculs spécifiques aux cas d’utilisation

En plus du calcul pour une application web par défaut, il est possible que vous deviez tenir compte de facteurs spécifiques pour les cas d’utilisation suivants. Les valeurs calculées doivent être ajoutées au calcul par défaut.

Considérations spécifiques aux ressources

Le traitement étendu des ressources numériques nécessite des ressources matérielles optimisées. Les facteurs les plus pertinents sont la taille des images et le débit maximal des images traitées.

Allouez au moins 16 Go de segment de mémoire et configurez le workflow Ressources de mise à jour de gestion des actifs numériques afin qu’il utilise le module Camera Raw pour l’intégration des images au format RAW.

Remarque :

Un débit d’images plus élevé signifie que les ressources de calcul doivent pouvoir suivre la cadence des E/S du système et vice versa. Par exemple, si des workflows sont lancés en important des images, le téléchargement de nombreuses images via WebDAV peut entraîner un journal des workflows en souffrance.

L’utilisation de disques distincts pour TarPM, le magasin de données et l’index de recherche peut aider à optimiser le comportement d’E/S du système (il est toutefois généralement préférable de conserver l’index de recherche localement).

Remarque :

Voir aussi le guide de performance des ressources.

Gestionnaire multisite

La consommation de ressources lors de l’utilisation du gestionnaire multisite AEM dans un environnement de création dépend en grande partie des cas d’utilisation spécifiques. Les facteurs de base sont les suivants :

  • Le nombre de Live Copies
  • La fréquence des déploiements
  • La taille de l’arborescence de contenu à déployer
  • La fonctionnalité de connexion des actions de déploiement

Le test du cas d’utilisation prévu avec un extrait de contenu représentatif peut vous aider à améliorer votre compréhension de la consommation des ressources. Si vous extrapolez les résultats avec la fréquence prévue, vous pouvez évaluer les ressources supplémentaires requises pour AEM MSM.

Tenez compte également du fait que les auteurs travaillant en parallèle subiront des effets secondaires au niveau des performances si les cas d’utilisation AEM MSM consomment davantage de ressources que prévu.

Considérations de dimensionnement pour AEM Communities

Les sites AEM qui incluent des fonctions AEM Communities (des sites de communauté) connaissent un haut niveau d’interaction des visiteurs du site (membres) dans l’environnement de publication.  

Les considérations de dimensionnement pour un site de communauté dépendent de l’interaction anticipée des membres de la communauté et de l’importance de disposer de performances optimales pour le contenu des pages.

Le contenu généré par les utilisateurs et soumis par les membres est stocké séparément du contenu des pages. Alors que la plate-forme AEM utilise un magasin de nœuds qui réplique le contenu du site de l’instance de création vers l’instance de publication, AEM Communities utilise un magasin simple et commun pour le contenu généré par les utilisateurs qui n’est jamais répliqué. 

Pour le magasin du contenu généré par les utilisateurs, il est nécessaire de sélectionner un fournisseur de ressources de stockage qui influence le déploiement sélectionné.
Voir 

Ce produit est distribué sous licence Creative Commons Attribution - Pas d’utilisation commerciale - Partage à l’identique 3.0 non transposé  Les publications Twitter™ et Facebook ne sont pas couvertes par les dispositions Creative Commons.

Mentions légales   |   Politique de confidentialité en ligne