Vous consultez actuellement l'aide de la version:

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 :

Les options de déploiement disponibles dans AEM sont illustrées ci-dessous (faites défiler l’écran 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

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

 

 

 

 

 

 

 

 

 

 

 

Remarque :

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.
  • 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 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 :

chlimage_1

Pour plus d’informations sur la plateforme AEM, reportez-vous à Qu’est-ce qu’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 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, voir Scénarios de déploiement classiques.

chlimage_1

Micronoyaux

Les micronoyaux servent de gestionnaires de persistence 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.

chlimage_1

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).

Remarque :

Adobe recommande TarMK comme technologie de persistance par défaut à utiliser par les clients pour les instances d’auteur et de publication AEM.

Attention :

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.

chlimage_1

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 requiert un grand nombre de ressources média, stockez-les dans le fichier ou l’entrepôt de données S3 pour pouvoir y accéder plus rapidement qu’en les stockant directement dans un MongoDB. 

Pour plus de détails sur les options de configuration disponibles, voir Configuration entrepôts de nœuds et de données.

chlimage_1

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 Oak et indexation.

Remarque :

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.

chlimage_1

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 comparaison

Remarque :

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

Remarque :

Les directives d’architecture minimale présentées ci-dessous concernent les environnements de production et les sites ayant un trafic élevé. Celles-ci ne sont pas les spécifications minimales requises pour exécuter 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 Dispatcher

Les consignes sur l’architecture pour AEM Sites et AEM Assets sont illustrées ci-dessous.

Remarque :

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

chlimage_1

Conseils d’architecture Tar pour AEM Assets

chlimage_1

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 des instructions sur la modification des paramètres, reportez-vous à cette 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 workflow transitoires Granite Parallèle Max. 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

Fichiers d’index Prefetch

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.
Processus Ressource de mise à jour de la gestion des actifs numériques Processus transitoire 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 Processus transitoire 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 :

  Nœud d’auteur
Serveur Bare metal hardware (HP)
Système d’exploitation RedHat Linux
Processeur/cœurs Intel(R) Xeon(R) CPU E5-2407 @2.40GHz, 8 cores 
RAM 32GB
Disque Magnetic
Java Oracle JRE Version 8
Tas JVM 16 Go
Produit  AEM 6.2
Entrepôt de nœuds TarMK
Entrepôt de données File DS 
Scénario Produit unique : Assets / 30 threads simultanés

Résultats du comparatif des performances

Remarque :

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.

chlimage_1
chlimage_1

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 Stockage de données 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 Dispatcher

Remarque :

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.

Remarque :

la réplication sans binaires doit être activée si l’entrepôt de données de fichier est partagé.

chlimage_1

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 des instructions sur la modification des paramètres, reportez-vous à cette 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 workflow transitoires Granite Parallèle Max. 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

Fichiers d’index Prefetch

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 :

  Nœud d’auteur Nœud MongoDB
Serveur Bare metal hardware (HP) Bare metal hardware (HP)
Système d’exploitation RedHat Linux RedHat Linux
Processeur/Cœurs Intel(R) Xeon(R) CPU E5-2407 @2.40GHz, 8 cores Intel(R) Xeon(R) CPU E5-2407 @2.40GHz, 8 cores 
RAM 32 Go 32 Go
Disque Magnetic - >1k IOPS Magnetic - >1k IOPS
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
Entrepôt de données Fichier DS  N/A
Scénario Produit unique : Assets / 30 threads simultanés Produit unique : Assets / 30 threads simultanés

Résultats de la comparaison des performances

Remarque :

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.

chlimage_1
chlimage_1

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 Standby 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

Remarque :

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

  Nœud d’auteur OAK Nœud MongoDB  
Serveur Bare metal hardware (HP) Bare metal hardware (HP)  
Système d’exploitation RedHat Linux RedHat Linux  
Processeur/cœurs Intel(R) Xeon(R) CPU E5-2407 @2.40GHz, 8 cœurs Intel(R) Xeon(R) CPU E5-2407 @2.40GHz, 8 cœurs  
RAM 32 Go 32 Go  
Disque Magnetic - >1k IOPS Magnetic - >1k IOPS  
Java Oracle JRE Version 8 N/A  
Tas JVM 16 Go 16 Go N/A  
Produit  AEM 6.2 MongoDB 3.2 WiredTiger  
Entrepôt de nœuds TarMK ou MongoMK N/A  
Entrepôt de données Fichier DS  N/A  
Scénario


Produit unique : Assets / 30 threads simultanés par exécution

 

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

chlimage_1

Caractéristiques techniques du scénario 2

Remarque :

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.

  Nœud d’auteur TarMK Nœud d’auteur MongoMK Nœud MongoDB
Serveur AWS c3.8xlarge AWS c3.8xlarge AWS c3.8xlarge
Système d’exploitation RedHat Linux RedHat Linux RedHat Linux
Processeur/Cœurs 32 32 32
RAM 60 Go 60 Go 60 Go
Disque SSD – 10k IOPS SSD – 10k IOPS SSD – 10k IOPS
Java Oracle JRE Version 8
Oracle JRE Version 8
N/A
Tas JVM 16 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
Entrepôt de données Fichier DS 
Fichier DS

N/A
Scénario



Cas d’utilisation vertical : média  / 2000 threads simultanés

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

chlimage_1

Conseils relatifs à l’évolutivité de l’architecture d’AEMִSites et AEM Assets

chlimage_1

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 Dispatcher
    • 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 Dispatcher
    • 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)
  • Amazon S3 est la banque de données recommandée pour un volume total de ressources au-delà de 5 To
    • 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 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 des écouteurs qui ne sont pas utilisés, etc.

Pour plus d’informations, consultez également la page Déploiements recommandés.

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