Show Menu
SUJETS×

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 :
Vous trouverez ci-dessous les options de déploiement disponibles pour AEM (faites défiler pour afficher toutes les options) :
AEM
Produit
Topologie
Système d’exploitation
Serveur d’applications
JRE
Sécurité
Micronoyau
Banque de données
Indexation
Serveur web
Navigateur
Marketing Cloud
Sites
Non-HA
Windows
CQSE
Oracle
LDAP
Tar
Segment
Propriétés
Apache 
Edge
Cible
Ressources
Publish-HA
Solaris
WebLo gic
IBM
SAML
MongoDB
Fichier
Lucene
IIS
IE
Analyse
Communautés
Author-CS
Red Hat
WebSphere
hp
Oauth
RDB/Oracle
S3/Azure
Solr
iPlanet
Firefox
Campagne
Forms
Déchargement d’auteur
HP-UX
Tomcat 
RDB/DB2
MongoDB
Chrome
Social
Mobile
Cluster d’auteur
IBM AIX 
JBoss 
RDB/MySQL
RDBMS
Safari
Public
Multi-site
ASRP
SUSE
RDB/SQLServer
Ressources
Commerce
MSRP
Apple OS
Activation
Dynamic Media
JSRP
Mobile
Brand Portal
J2E
AoD
LiveFyre
Screens
Sécurité des documents
Gestion des processus
application de bureau
Les directives de performance s’appliquent principalement à AEM Sites.

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 :
For more information on the AEM platform, see What is 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. The third building block is the Dispatcher which is a module that handles caching and URL filtering and is installed on the webserver. 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 noyaux micro utilisés avec 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é. For additional information about Micro Kernels, see the Recommended Deployments page.

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) .
Adobe recommande TarMK comme technologie de persistance par défaut à utiliser par les clients pour les instances d’auteur et de publication AEM.
La prise en charge du micronoyau de la base de données relationnelle est limitée. Contactez l’assistance clientèle d’Adobe avant d’utiliser ce type de micronoyau.

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.
For further details on the available configuration options, see Configuring Node and Data Stores .
Adobe recommande d’utiliser l’option de déploiement d’AEM sur Azure ou Amazon Web Services (AWS) en utilisant les services d’Adobe Managed Services, où les clients pourront bénéficier d’une équipe possédant l’expérience et les compétences de déploiement et d’opération d’AEM pour les environnements de cloud computing. Please see our additional documentation on Adobe Managed Services .
Pour des recommandations sur le déploiement d’AEM sur Azure ou AWS, en dehors des Adobe Managed Services, nous vous recommandons vivement de travailler directement avec votre fournisseur cloud ou avec l’un de nos partenaires prenant en charge le déploiement d’AEM dans l’environnement de cloud de votre choix. Le partenaire ou fournisseur cloud que vous choisissez est responsable du dimensionnement, de la conception et de l’implémentation de l’architecture qu’ils vont prendre en charge pour répondre à vos besoins spécifiques en matière de performance, de chargement, d’évolutivité et de sécurité.
For additional details also see the technical requirements page.

Recherche

Les fournisseurs d’index personnalisés utilisés avec AEM sont répertoriés dans cette section. To know more about indexing, see Oak Queries and Indexing .
Pour la plupart des déploiements, Adobe conseille d’utiliser l’index Lucene. Nous vous recommandons d’utiliser Solr uniquement pour son évolutivité dans les déploiements spécialisés et plus complexes.

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

Tous les tests comparatifs affichés sur cette page ont été réalisés dans un environnement de laboratoire.
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

Les directives d’architecture minimale présentées ci-dessous concernent les environnements de production et les sites ayant un trafic élevé. These are not the minimum specifications needed to run AEM.
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.
La réplication sans binaires doit être ACTIVÉE si l’entrepôt de données du fichier est partagé.
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. For instructions on how to change the settings, see this page .
Configuration Paramètre Valeur Description
Files d’attente des tâches Sling queue.maxparallel Définissez la valeur sur la moitié du nombre de cœurs de processeur. Par défaut, le nombre de threads simultanés par file d’attente des tâches est égal au nombre de cœurs de processeur.
File d’attente des workflows transitoires Granite Max Parallel Définissez la valeur sur la moitié du nombre de cœurs de processeur.
Paramètres JVM
Doak.queryLimitInMemory
Doak.queryLimitReads
Dupdate.limit
Doak.fastQuerySize
500 000
100 000
250 000
True
Ajoutez ces paramètres JVM dans le script de démarrage AEM afin d’empêcher les requêtes coûteuses de surcharger les systèmes.
Configuration de l’index Lucene
CopyOnRead
CopyOnWrite
Prefetch Index Files
Activé
Activé
Activé
Pour plus de détails sur les paramètres disponibles, voir cette page .
Entrepôt de données = Entrepôt de données S3
maxCachedBinarySize
cacheSizeInMB
1048576 (1 Mb) ou plus petit
2-10 % de la taille maximale du tas
Voir aussi Configurations de la banque de données .
Workflow Ressource de mise à jour de la gestion des actifs numériques Transient Workflow vérifié Ce workflow gère la mise à jour des ressources.
Écriture différée des métadonnées de gestion des actifs numériques Transient Workflow vérifié Ce workflow gère l’écriture différée XMP au format binaire d’origine et définit la date de la dernière modification dans jcr.

Comparatif des performances TarMK

Spécifications techniques

Les tests comparatifs ont été effectués selon les spécifications suivantes :
Noeud Auteur
Serveur
Matériel métallique nu (HP)
Système d’exploitation
RedHat Linux
UC / Coeurs
Processeur Intel(R) Xeon(R) E5-2407 @2.40GHz, 8 coeurs
Mémoire RAM
32 Go
Disque
Magnétique
Java
Oracle JRE version 8
Tas JVM
16 Go
Produit
AEM 6.2
Entrepôt de nœuds
TarMK
Banque de données
Fichier DS
Scénario
Produit unique : Ressources / 30 threads simultanés

Résultats de la comparaison des performances

Les chiffres présentés ci-dessous ont été normalisés en prenant 1 comme ligne de base et ne représentent pas les chiffres de débit réels.

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.
For more information about TarMK, see Deployment Scenarios and Mongo Storage .

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
Dans les environnements de production, MongoDB sera toujours utilisé comme un ensemble de réplication avec une instance principale et deux instances secondaires. Les lectures et écritures sont envoyées à l’instance principale alors que les lectures peuvent être envoyées aux instances secondaires. Si le stockage n’est pas disponible, une des instances secondaires peut être remplacée par un arbitre, mais les ensembles de réplication MongoDB doivent toujours être composés d’un nombre impair d’instances.
La réplication sans binaires doit être ACTIVÉE si l’entrepôt de données du fichier est partagé.

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. For instructions on how to change the settings, see this page .
Configuration Paramètre Valeur (par défaut) Description
Files d’attente des tâches Sling queue.maxparallel Définissez la valeur sur la moitié du nombre de cœurs de processeur. Par défaut, le nombre de threads simultanés par file d’attente des tâches est égal au nombre de cœurs de processeur.
File d’attente des workflows transitoires Granite Max Parallel Définissez la valeur sur la moitié du nombre de cœurs de processeur.
Paramètres JVM
Doak.queryLimitInMemory
Doak.queryLimitReads
Dupdate.limit
Doak.fastQuerySize
Doak.mongo.maxQueryTimeMS
500 000
100 000
250 000
True
60 000
Ajoutez ces paramètres JVM dans le script de démarrage AEM afin d’empêcher les requêtes coûteuses de surcharger les systèmes.
Configuration de l’index Lucene
CopyOnRead
CopyOnWrite
Prefetch Index Files
Activé
Activé
Activé
Pour plus d’informations sur les paramètres disponibles, voir cette page .
Entrepôt de données = Entrepôt de données S3
maxCachedBinarySize
cacheSizeInMB
1048576 (1 Mb) ou plus petit
2-10 % de la taille maximale du tas
Voir aussi Configurations de la banque de données .
DocumentNodeStoreService
cache
nodeCachePercentage
childrenCachePercentage
diffCachePercentage
docChildrenCachePercentage
prevDocCachePercentage
persistentCache
2048
35 (25)
20 (10)
30 (5)
10 (3)
4 (4)
./cache,size=2048,binary=0,-compact,-compress
La taille du cache par défaut est fixée à 256 Mo.
Impacte le temps qu’il faut pour exécuter l’invalidation du cache.
oak-observation
thread pool
length
min et max = 20
50 000

Comparaison des performances MongoMK

Spécifications techniques

Les tests comparatifs ont été effectués selon les spécifications suivantes :
Noeud d’auteur
Noeud MongoDB
Serveur
Matériel métallique nu (HP)
Matériel métallique nu (HP)
Système d’exploitation
RedHat Linux
RedHat Linux
UC / Coeurs
Processeur Intel(R) Xeon(R) E5-2407 @2.40GHz, 8 coeurs
Processeur Intel(R) Xeon(R) E5-2407 @2.40GHz, 8 coeurs
Mémoire RAM
32 Go
32 Go
Disque
Magnétique - >1 000 E/S
Magnétique - >1 000 E/S
Java
Oracle JRE version 8
N/A
Tas JVM
16 Go
N/A
Produit
AEM 6.2
MongoDB 3.2 WiredTiger
Entrepôt de nœuds
MongoMK
N/A
Banque de données
Fichier DS
N/A
Scénario
Produit unique : Ressources / 30 threads simultanés
Produit unique : Ressources / 30 threads simultanés

Résultats de la comparaison des performances

Les chiffres présentés ci-dessous ont été normalisés en prenant 1 comme ligne de base et ne représentent pas les chiffres de débit réels.

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
  • Provides a failover mechanism - see Cold Standby for more details
  • 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

Les chiffres présentés ci-dessous ont été normalisés en prenant 1 comme ligne de base et ne représentent pas les chiffres de débit réels.

Caractéristiques techniques du scénario 1

Noeud OAK de l’auteur Noeud MongoDB
Serveur Matériel métallique nu (HP) Matériel métallique nu (HP)
Système d’exploitation RedHat Linux RedHat Linux
UC / Coeurs Processeur Intel(R) Xeon(R) E5-2407 @2.40GHz, 8 coeurs Processeur Intel(R) Xeon(R) E5-2407 @2.40GHz, 8 coeurs
Mémoire RAM 32 Go 32 Go
Disque Magnétique - >1 000 E/S Magnétique - >1 000 E/S
Java Oracle JRE version 8 N/A
JVM Heap16 Go 16 Go N/A
Produit AEM 6.2 MongoDB 3.2 WiredTiger
Entrepôt de nœuds TarMK ou MongoMK N/A
Banque de données Fichier DS N/A
Scénario
Produit unique : Ressources / 30 threads simultanés par exécution

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

Caractéristiques techniques du scénario 2

Pour activer le même nombre d’auteurs avec MongoDB qu’avec un système TarMK, vous aurez besoin d’un cluster avec deux nœuds AEM. Un cluster MongoDB de quatre nœuds peut gérer 1,8 fois le nombre d’auteurs d’une instance TarMK. Un cluster MongoDB de huit nœuds peut gérer 2,3 fois le nombre d’auteurs d’une instance TarMK.
Noeud TarMK d’auteur Noeud MongoMK de l’auteur Noeud MongoDB
Serveur AWS c3.8xlarge AWS c3.8xlarge AWS c3.8xlarge
Système d’exploitation RedHat Linux RedHat Linux RedHat Linux
UC / Coeurs 32 32 32
Mémoire RAM 60 Go 60 Go 60 Go
Disque SSD - 10 000 E/S par seconde SSD - 10 000 E/S par seconde SSD - 10 000 E/S par seconde
Java Oracle JRE version 8 Oracle JRE version 8 N/A
JVM Heap16 Go 30 Go 30 Go N/A
Produit AEM 6.2 AEM 6.2 MongoDB 3.2 WiredTiger
Entrepôt de nœuds TarMK MongoMK N/A
Banque de données Fichier DS Fichier DS N/A
Scénario
Cas d’utilisation vertical : Fils simultanés Media/2000

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)
  • When using 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 sensiblement 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 .