Arborescence de la performance performance-tree
- Rubriques :
- Administration
Créé pour :
- Administration
Portée scope
Le diagramme suivant est destiné à fournir des conseils sur les étapes à suivre pour résoudre les problèmes de performances. Il est divisé en cinq sections afin de faciliter la lecture.
Chaque étape du diagramme est associée à une ressource ou à une recommandation.
Conditions préalables et hypothèses prerequisites-and-assumptions
L’hypothèse est qu’un problème de performance est observé sur une page donnée (une console d’AEM ou une page web) et peut être reproduit de manière cohérente. Disposer d’un moyen de tester ou de surveiller les performances est une condition préalable à l’ouverture de l’enquête.
L’analyse commence à l’étape 0. L’objectif est de déterminer quelle entité (Dispatcher, hôte externe ou AEM) est responsable du problème de performance, puis de découvrir la zone (serveur ou réseau) qui doit être étudiée.
Section 1 section
Section 2 section-1
Section 3 section-2
Section 4 section-3
Section 5 section-4
Liens de référence reference-links
Vous pouvez utiliser l’analyse des requêtes HTTP standard dans le navigateur pour analyser le flux de requêtes. Pour plus d’informations sur la manière d’effectuer cette analyse sur Chrome, veuillez consulter :
HEAD
à AEM pour authentification avant de diffuser la ressource mise en cache. Recherchez les requêtes HEAD
dans le access.log
d’AEM. Pour plus d’informations, consultez la section Journalisation.Examinez la couche réseau pour détecter les problèmes de saturation et de latence.
Pour le niveau de création, il est recommandé que la latence ne dépasse pas 100 millisecondes.
Pour plus d’informations sur les conseils d’optimisation des performances, reportez-vous à cette page.
Vous pouvez identifier les requêtes lentes en analysant le request.log
ou à l’aide de rlog.jar
.
Pour plus d’informations sur l’utilisation de rlog.jar, consultez cette page.
Voir Recherche de requêtes avec de longues durées à l’aide de rlog.jar.
- Service de synchronisation d’Assets
- Instances multiples de gestion des ressources numériques
- Article présentant des conseils sur l’optimisation des performances disponible ici.
Comment améliorer le ratio de cache ; faire en sorte que les requêtes puissent être mises en cache (bonnes pratiques du Dispatcher)
Tenez également compte des paramètres ci-dessous pour optimiser vos configurations de mise en cache.
- Définissez une règle de non-mise en cache pour une requête HTTP qui n’est pas GET.
- Configurez les chaînes de requête pour qu’elles ne puissent pas être mises en cache.
- Ne mettez pas en cache les URL avec des extensions manquantes.
- En-têtes d’authentification du cache (possibles depuis la version 4.1.10 du Dispatcher)
Vous pouvez télécharger la dernière version du Dispatcher à cet emplacement :
et 47
.
L’en-tête Keep-Alive
est-il présent dans les différentes requêtes de réutilisation des connexions ? Dans le cas contraire, cela signifie que chaque requête mène à établir une nouvelle connexion, entraînant ainsi une surcharge inopportune. (Analyse des requêtes HTTP standard dans le navigateur)
Vous pouvez accéder à l’Outil Serveur proxy pour vérifier les connexions Keep-alive.
- Concaténation de ressources (images, sprites CSS, JSON)
- Incorporation de bibliothèques clientes
- Création de dossiers dans la bibliothèque cliente : consultez la section Utilisation d’incorporations pour réduire les demandes.