Show Menu
SUJETS×

Contrôle et maintien de votre instance AEM

Une fois les instances AEM déployées, certaines tâches sont nécessaires pour surveiller et conserver leur fonctionnalité, leur performance et leur intégrité.
Un facteur clé est qu’en vue d’identifier des problèmes potentiels, vous devez savoir comment vos systèmes fonctionnent dans des conditions normales. Le meilleur moyen pour cela est de surveiller le système et de collecter des informations sur une période donnée.
Vérification
Considérations
Commentaires/actions
Plan de sauvegarde.
Découvrez comment sauvegarder votre instance .
Plan de reprise sur sinistre.
Consignes de reprise sur sinistre de votre entreprise.
Un système de suivi des erreurs est disponible pour signaler des problèmes.
Par exemple, bugzilla , jira , ou plusieurs autres.
Les systèmes de fichier sont surveillés.
Le référentiel CRX se « bloque » s’il n’y a pas suffisamment d’espace disque disponible. Il reprendra une fois qu’il y aura suffisamment d’espace disponible.
" *ERROR* LowDiskSpaceBlocker " De tels messages s’affichent dans le fichier journal lorsque l’espace disque est faible.
Les fichiers journaux sont surveillés.
Le contrôle du système s’exécute (constamment) en arrière-plan.
Cela comprend l’usage du processeur, de la mémoire, du disque et du réseau. En utilisant, par exemple, iostat / vmstat / perfmon.
Les données enregistrées sont visualisées et peuvent être utilisées pour suivre les problèmes de performance. Les données brutes sont accessibles.
Cela comprend le décompte des demandes pour surveiller les niveaux de trafic.
Si une perte de performance significative ou sur le long terme est constatée, il convient d’entreprendre une investigation approfondie.
Vous surveillez vos agents de réplication . ``
Purge régulière des instances de workflow.
Taille du référentiel et performance des workflows.

Sauvegardes

Il est recommandé de sauvegarder :
  • L’installation de votre logiciel, avant ou après des modifications importantes dans la configuration
  • Le contenu conservé dans le référentiel - régulièrement
Votre entreprise a probablement établi un protocole de sauvegarde que vous devez suivre, des considérations supplémentaires sur ce qui doit être sauvegardé et quand inclure :
  • L’importance du système et des données.
  • À quelle fréquence les modifications sont-elles apportées au logiciel ou aux données ?
  • Le volume de données ; la capacité peut parfois poser problème, de même que la durée nécessaire pour effectuer la sauvegarde.
  • Si votre sauvegarde peut être effectuée au moment où les utilisateurs sont en ligne ; et si possible, quel est l’impact sur la performance.
  • La position géographique des utilisateurs ; quel est le meilleur moment pour effectuer la sauvegarde (pour minimiser l’impact) ?
  • Votre stratégie de reprise après sinistre; y a-t-il des directives sur l’emplacement du stockage de données de sauvegarde (par exemple, hors site et médias spécifiques etc.).
Une sauvegarde complète est souvent effectuée à intervalles réguliers (par exemple de manière quotidienne, hebdomadaire ou mensuelle), avec des sauvegardes incrémentielles (par exemple par heure, jour ou semaine).
Lors de l’exécution des sauvegardes de vos instances de production, des tests doivent être effectués pour vous assurer que la sauvegarde peut être restaurée.
Sans cela, la sauvegarde est potentiellement inutile (au pire des cas).
# Pour plus d’informations sur les performances de sauvegarde, consultez la section Performance de sauvegarde .

Prise en charge de votre installation logicielle

Après l’installation de votre configuration ou des modifications importantes au sein de celle-ci, effectuez une sauvegarde de votre installation logicielle.
Pour ce faire, vous devez sauvegarder entièrement votre référentiel , puis :
  1. Arrêtez AEM.
  2. Back up the entire <cq-installation-dir> from your file system.
Si vous gérez un serveur d’application tiers, des fichiers supplémentaires peuvent se trouver sur un emplacement différent et doivent galement être pris en charge. Découvrez comment installer AEM avec un serveur d’application pour plus d’informations sur la configuration des serveurs d’applications. #(/content/docs/en/aem/6-3/deploy/installing.md#installing adobe Experience Manager with an application server)
La sauvegarde incrémentielle de l’entrepôt de données de fichier est prise en charge ; lorsque vous utilisez la sauvegarde incrémentielle pour d’autres composants (tels que l’index Lucene), assurez-vous que les fichiers supprimés sont également marqués comme supprimé dans la sauvegarde.
La duplication du disque peut également être utilisée comme mécanisme de sauvegarde.

Sauvegarde de votre référentiel

La section Sauvegarde et restauration de la documentation CRX permet de couvrir tous les problèmes liés aux sauvegardes du référentiel CRX.
Pour des détails sur l’exécution d’une sauvegarde « à chaud » en ligne, voir Création d’une sauvegarde en ligne .

Purge de version

L’outil Purge de versions est prévu pour la purge des versions d’un nœud ou d’une hiérarchie de nœuds dans votre référentiel. Son principal objectif est de vous aider à réduire la taille du référentiel en supprimant les anciennes versions de vos nœuds.
Cette section traite des opérations de maintenance liées à la fonctionnalité de création de versions d’AEM. L’outil Purge de versions est prévu pour la purge des versions d’un nœud ou d’une hiérarchie de nœuds dans votre référentiel. Son principal objectif est de vous aider à réduire la taille du référentiel en supprimant les anciennes versions de vos nœuds.

Présentation

L’outil Purge de versions est disponible dans la console Outils ​sous​ Versions ​ou directement à l’adresse :
https://<server>:<port>/etc/versioning/purge.html
Chemin de Chemin absolu sur lequel la purge doit être effectuée. Vous pouvez sélectionner le chemin de début en cliquant sur le navigateur d’arborescence du référentiel.
Récursif Lors de la purge de données, vous pouvez choisir entre exécuter l’opération sur un noeud ou sur une hiérarchie entière en sélectionnant Récursif. Dans ce cas, le chemin donné définit le nœud racine de la hiérarchie.
Nombre maximal de versions à conserver Nombre maximal de versions à conserver pour un noeud. Lorsque ce nombre dépasse la valeur, les versions les plus anciennes sont purgées.
âge maximal de la version L’âge maximal de la version d’un noeud. Lorsque l’âge d’une version dépasse cette valeur, elle est purgée.
Exécution à sec Comme la suppression des versions de votre contenu est définitive et ne peut pas être annulée sans la restauration d’une sauvegarde, l’outil Purger les versions fournit un mode d’exécution à sec qui vous permet de les versions purgées. Pour lancer le mode Exécution d’essai du processus de purge, cliquez sur Exécution d’essai.
Purger Lancez la purge des versions sur le noeud défini par le chemin d’accès du.

Purge des versions d’un site web

Pour purger les versions d’un site web, procédez comme suit :
  1. Accédez à la console Outils , sélectionnez Versions ​et double-cliquez sur Purger les versions.
  2. Set the start path of the content to be purged (e.g. /content/geometrixx-outdoors ).
    • Si vous souhaitez purger uniquement le nœud défini par le chemin, désélectionner Récursif .
    • Si vous souhaitez purger le nœud défini par le chemin et ses descendants, sélectionnez Récursif .
  3. Définissez le nombre maximal de versions (pour chaque nœud) que vous souhaitez conserver. Laissez le paramètre vide si vous ne souhaitez pas l’utiliser.
  4. Définissez l’âge maximal de la version en jours (pour chaque nœud) que vous souhaitez conserver. Laissez le paramètre vide si vous ne souhaitez pas l’utiliser.
  5. Cliquez sur Exécution d’essai pour prévisualiser le processus de purge.
  6. Cliquez sur Purge pour lancer le processus.
Les nœuds purgés ne peuvent pas être rétablis sans restaurer le référentiel. Vous devez veiller à votre configuration. Nous vous recommandons de toujours lancer une exécution d’essai avant la purge.

Analyse de la console

Les processus Exécution d’essai et Purge répertorient tous les noeuds qui ont été traités. Au cours du processus, un nœud peut avoir l’un des états suivants :
  • ignore (not versionnable) : le noeud ne prend pas en charge le contrôle de version et est ignoré pendant le processus.
  • ignore (no version) : le noeud n’a aucune version et est ignoré pendant le processus. "
  • retained : le noeud n’est pas purgé.
  • purged : le noeud est purgé.
Par ailleurs, la console affiche des informations utiles sur les versions :
  • V 1.0 : numéro de version.
  • V 1.0.1 * : l’étoile indique que la version est active.
  • Thu Mar 15 2012 08:37:32 GMT+0100 : date de la version.
Dans l’exemple suivant :
  • Les versions Shirts sont purgées parce que leur âge de version est supérieur à 2 jours.
  • The Tonga Fashions! versions are purged because their number of versions is greater than 5.

Utilisation des enregistrements et des fichiers journaux d’audit

Les enregistrements et les fichiers journaux d’audit associés à Adobe Experience Manager (AEM) sont disponibles dans différents emplacements. Ce qui suit vise à vous donner un aperçu de ce que vous pouvez trouver, à quels emplacements.

Utilisation des journaux

La gestion du contenu web d’AEM permet d’enregistrer de manière détaillée les journaux. Après avec décompressé et démarré Quickstart, vous pouvez trouver les journaux à l’adresse suivante :
  • <cq-installation-dir>/crx-quickstart/logs/
  • <cq-installation-dir>/crx-quickstart/repository/

Rotation de fichier journal

La rotation de fichier journal fait référence au processus qui limite la croissance du fichier par la création régulière d’un nouveau fichier. Dans AEM, un fichier journal appelé error.log est activé une fois par jour, selon les règles en place :
  • Le fichier error.log est renommé selon le modèle .yyyy-MM-dd . Par exemple, le 11 juillet , le fichier journal actuel est renommé error.log-2010-07-10 -2010-, , puis un nouveau fichier error.og est créé.
  • Les fichiers journaux précédents ne sont pas supprimés, il vous incombe donc de nettoyer régulièrement les anciens fichiers journaux afin de limiter l'utilisation du disque.
Si vous mettez à niveau votre installation d’AEM, notez que tout fichier journal existant qui n’est plus utilisé par AEM restera sur le disque. Vous pouvez les supprimer en toute sécurité. Toutes les nouvelles entrées de journal seront écrites dans les nouveaux fichiers journaux.

Recherche de fichiers journaux

Divers fichiers journaux sont conservés sur le serveur de fichiers sur lequel vous avez installé AEM :
  • <cq-installation-dir>/crx-quickstart/logs
    • access.log Toutes les demandes d’accès à la gestion du contenu web d’AEM et au référentiel sont enregistrées ici.
    • audit.log Les actions de modération sont enregistrées ici.
    • error.log Les messages d’erreur (de différents niveaux de gravité) sont enregistrés ici.
    • ImageServer-<PortId>-yyyy>-<mm>-<dd>.log Ce journal n'est utilisé que si Dynamic Media est activé. Il fournit des statistiques et des informations d’analyse utilisées pour analyser le comportement du processus interne ImageServer.
    • request.log Chaque demande d’accès est enregistrée ici en même temps que la réponse.
    • s7access-<yyyy>-<mm>-<dd>.log Ce journal n'est utilisé que si Dynamic Media est activé. The s7access log records each request made to Dynamic Media through /is/image and /is/content .
    • stderr.log Contient les messages d’erreur, de différents niveaux de gravité, générés lors du démarrage. By default the log level is set to Warning ( WARN )
    • stdout.log Contient des messages de journaux indiquant les événements pendant le démarrage.
    • upgrade.log Fournit un journal de toutes les opérations de mise à niveau qui s’exécutent à partir des com.day.compat.codeupgrade et des com.adobe.cq.upgradesexecutor packages.
  • <*cq-installation-dir*>/crx-quickstart/repository
    • revision.log Révision des informations de journalisation.
Les journaux ImageServer et s7access ne sont pas inclus dans le Télécharger le package complet ​généré à partir de la page ​system/console/status-Bundlelist. For support purposes, if you have Dynamic Media issues, please also append the ImageServer and s7access logs when you contact Customer Support.

Activation du niveau de journalisation DEBUG

Le niveau de journalisation par défaut ( configuration des journaux Apache Sling ) consiste en des informations, les messages de débogage n’y sont donc pas consignés.
Pour activer le niveau de journalisation de débogage pour un journal, définissez la propriété org.apache.sling.commons.log.level pour le débogage dans le référentiel. For example, on /libs/sling/config/org.apache.sling.commons.log.LogManager to configure the global Apache Sling Logging .
Ne laissez pas le journal au niveau de débogage plus longtemps que nécéssaire, car cela génère un grand nombre d’entrées, causant ainsi du gaspillage de ressources.
Une ligne dans le fichier de débogage commence généralement par DEBUG, puis fournit le niveau de journalisation, l’action d’installation et le message du journal. Par exemple :
DEBUG 3 WebApp Panel: WebApp successfully deployed

Les niveaux de journalisation sont les suivants :
0
Erreur fatale
L'action a échoué et le programme d'installation ne peut pas continuer.
1
Erreur
L'action a échoué. L’installation se poursuit, mais une partie de la gestion du contenu web d’AEM n’a pas été installée correctement et ne fonctionnera pas.
2
Avertissement
L'action a réussi mais a rencontré des problèmes. La gestion du contenu web d’AEM risque de ne pas fonctionner correctement.
3
Informations
L'action a réussi.

Création d’un fichier journal personnalisé

Lorsque vous utilisez Adobe Experience Manager, vous disposez de plusieurs méthodes pour gérer les paramètres de configuration pour ces services. Consultez Configuration OSGi pour obtenir plus de détails et les pratiques recommandées.
Dans certains cas, vous pouvez créer un fichier journal personnalisé avec un niveau de journalisation différent. Vous pouvez le faire depuis le référentiel en procédant comme suit :
  1. If not already existing, create a new configuration folder ( sling:Folder ) for your project /apps/<*project-name*>/config .
  2. Under /apps/<*project-name*>/config , create a node for the new Apache Sling Logging Logger Configuration :
    • Nom : org.apache.sling.commons.log.LogManager.factory.config-<*identifier*> (comme il s’agit d’un journal)
      Where <*identifier*> is replaced by free text that you (must) enter to identify the instance (you cannot omit this information).
      Par exemple, org.apache.sling.commons.log.LogManager.factory.config-MINE
    • Type: sling:OsgiConfig
    Although not a technical requirement, it is advisable to make <*identifier*> unique.
  3. Définissez les propriétés suivantes sur ce nœud :
    • Nom: org.apache.sling.commons.log.file
      Type : Chaîne
      Valeur : spécifiez le fichier journal; par exemple, logs/myLogFile.log
    • Nom: org.apache.sling.commons.log.names
      Type : Chaîne # (Chaîne + Multi)
      Valeur : spécifiez les services OSGi pour lesquels le journal doit enregistrer les messages ; par exemple, tous les éléments suivants :
      • org.apache.sling
      • org.apache.felix
      • com.day
    • Nom: org.apache.sling.commons.log.level
      Type : Chaîne
      Valeur : spécifier le niveau de journal requis ( debug , info , warn ou error ); par exemple debug
    • Configurez les autres paramètres en fonction de vos besoins :
      • Nom: org.apache.sling.commons.log.pattern
        Type: String
        Valeur : préciser le modèle du message du journal, le cas échéant; par exemple,
        {0,date,dd.MM.yyyy HH:mm:ss.SSS} *{4}* [{2}] {3} {5}
    org.apache.sling.commons.log.pattern prend en charge jusqu’à six arguments.
    {0} L’horodatage de type java.util.Date {1} l’indicateur de journal {2} le nom du thread actuel {3} le nom de l’enregistreur {4} le niveau de journalisation {5} le message de journal
    Si l’appel de journal comprend un Throwable , la trace de pile est ajoutée au message.
    org.apache.sling.commons.log.names doit avoir une valeur.
    Log writer paths are relative to the crx-quickstart location. Par conséquent, un fichier journal spécifié en tant que : logs/thelog.log
    écrit à : ` ` `<*cq-installation-dir*>/ crx-quickstart/logs/thelog.log . Et un fichier journal spécifié en tant que : ../logs/thelog.log`
    écrit à un répertoire : <*cq-installation-dir*>/logs/ "(c’est-à-dire en regard de < cq-installation-dir >/ crx-quickstart/ )
  4. Cette étape est nécessaire uniquement lorsqu’un nouvel auteur est nécessaire (c’est-à-dire avec une configuration différente de l’auteur par défaut).
    Une nouvelle configuration d’auteur de journalisation est uniquement nécessaire lorsque celle par défaut n’est pas appropriée.
    Si aucun auteur explicite n’est configuré, le système génère automatiquement un auteur implicite par défaut.
    Under /apps/<*project-name*>/config , create a node for the new Apache Sling Logging Writer Configuration :
    • Nom : org.apache.sling.commons.log.LogManager.factory.writer-<*identifier*> (comme il s’agit d’un auteur)
      Comme pour le Logger, <*identifier*> est remplacé par du texte libre que vous (devez) entrez pour identifier l'instance (vous ne pouvez pas omettre ces informations). Par exemple, org.apache.sling.commons.log.LogManager.factory.writer-MINE
    • Type: sling:OsgiConfig
    Although not a technical requirement, it is advisable to make <*identifier*> unique.
    Définissez les propriétés suivantes sur ce nœud :
    • Nom: org.apache.sling.commons.log.file
      Type: String
      Valeur : spécifiez le fichier journal de sorte qu'il corresponde au fichier spécifié dans le journal ;
      pour cet exemple, ../logs/myLogFile.log .
    • Configurez les autres paramètres en fonction de vos besoins :
      • Nom: org.apache.sling.commons.log.file.number
        Type: Long
        Value: specify the number of log files you want kept; for example, 5
      • Nom: org.apache.sling.commons.log.file.size
        Type: String
        Value: specify as required to control file rotation by size/date; for example, '.'yyyy-MM-dd
    org.apache.sling.commons.log.file.size contrôle la rotation du fichier journal en fonction du paramètre suivant :
    • une taille maximale de fichier
    • une planification heure/date pour indiquer quand un nouveau fichier sera créé (et le fichier existant renommé selon le modèle de nom).
    • Une taille maximale peut être spécifiée par un nombre. If no size indicator is given, then this is taken as the number of bytes, or you can add one of the size indicators - KB , MB , or GB (case is ignored).
    • Une planification heure/date peut être spécifiée sous la forme d’un modèle java.util.SimpleDateFormat . Cela définit le délai au bout duquel le fichier subit une rotation ; de même que le suffixe ajouté au fichier pivoté (pour identification). La valeur par défaut est '.'yyyy-MM-dd (pour la rotation quotidienne du journal). Par exemple, à minuit le 20 janvier 2010 (ou pour être précis, lorsque le premier message de journal après cette heure est envoyé), ../logs/error.log sera renommé ../logs/error.log.2010-01-20. La journalisation du 21 janvier sera générée vers ../logs/error.log (nouveau et vide) jusqu’à ce qu’elle soit remplacée lors de la prochaine modification quotidienne. | '.'yyyy-MM | Rotation au début de chaque mois | |---|---| | '.'yyyy-ww | Rotation au premier jour de chaque semaine (dépend du paramètre régional). | | '.'yyyy-MM-dd | Rotation à minuit tous les jours. | | '.'yyyy-MM-dd-a | Rotation à minuit et midi de chaque jour. | | '.'yyyy-MM-dd-HH | Rotation au sommet de chaque heure. | | '.'yyyy-MM-dd-HH-mm | Rotation au début de chaque minute. | Remarque : Lors de la spécification d’une heure/date :
    1. Vous devez placer le texte littéral "escape" dans une paire de guillemets simples (' '); afin d’éviter que certains caractères ne soient interprétés comme des lettres de modèle.
    1. Utilisez uniquement les caractères autorisés pour un nom de fichier valide n’importe où dans l’option.
  5. Lisez votre nouveau fichier journal avec l’outil sélectionné.
    The log file created by this example will be ../crx-quickstart/logs/myLogFile.log .
The Felix Console also provides information about Sling Log Support at ../system/console/slinglog ; for example https://localhost:4502/system/console/slinglog .

Recherche des enregistrements d’audit

Les enregistrements d’audit sont effectués pour fournir un registre de qui a fait quoi et quand. Les enregistrements d’audit sont générés pour les événements de gestion du contenu web d’AEM et OSGi.

Enregistrements d’audit de la gestion du contenu web d’AEM affiché lors de la création de page

  1. Ouvrez une page.
  2. Depuis le sidekick, vous pouvez sélectionner l’onglet avec l’icône de verrouillage, puis double-cliquer sur Journal d’audit…
  3. Une nouvelle fenêtre s’affiche et présente la liste des enregistrements d’audit pour la page en cours.
  4. Cliquez sur OK pour fermer la fenêtre.

Enregistrements d’audit de la gestion du contenu web d’AEM dans le référentiel

Within the /var/audit folder, audit records are held according to the resource. Vous pouvez faire défiler la page vers le bas jusqu’à ce que vous puissiez voir les différents enregistrements et les informations qu’ils contiennent.
Ces entrées contiennent les mêmes informations que lors de la modification d’une page.

Enregistrements d’audit OSGi dans la console web

OSGi events also generate audit records which can be seen from the Configuration Status tab -> Log Files ​tab in the AEM Web Console:

Surveillance de vos agents de réplication

Vous pouvez surveiller vos files d’attente de réplication pour détecter le moment où une file d’attente est arrêtée ou a bloquée, ce qui peut indiquer un problème avec une instance de publication ou le système externe :
  • toutes les files d’attente requises sont-elles activées ?
  • les files d’attente désactivées sont-elles à nouveau requises ?
  • all enabled queues should have the status idle or active , which indicate normal operation; no queues should be blocked , which is often a sign of problems on the receivers side.
  • Si la taille de la file d’attente augmente au fil du temps, cela peut indiquer qu’elle est bloquée.
Pour surveiller un agent de réplication :
  1. Accédez à l’onglet Outils dans AEM.
  2. Cliquez sur Réplication .
  3. Double-cliquez sur le lien vers les agents pour l’environnement approprié (le volet à gauche ou le volet de droite) ; par exemple Agents sur l’auteur .
    La fenêtre affiche une présentation de tous vos agents de réplication pour l’environnement de création, y compris leur cible et leur état.
  4. Cliquez sur le nom de l’agent appropriée (qui est un lien) pour afficher des informations détaillées sur cet agent :
    Vous pouvez effectuer les opérations suivantes :
    • Vérifier si l’agent est activé.
    • Afficher les cibles des réplications.
    • Vérifier si la file d’attente de réplication est activée.
    • Vérifier s’il existe des éléments dans la file d’attente.
    • Actualiser ou effacer pour mettre à jour l’affichage des entrées de file d’attente ; cela vous permet de voir les éléments entrer et sortir de la file d’attente.
    • Consulter le journal pour accéder au journal de toutes actions de l’agent de réplication.
    • Tester la connexion à l’instance cible.
    • Forcer un nouvel essai sur tous les éléments de la file d’attente si nécessaire.
    N’utilisez pas le lien « Tester la connexion » pour la boîte d’envoi de la réplication inverse sur l’instance de publication. Si un test de réplication est effectué pour une file d’attente de la boîte d’envoi, les éléments qui sont plus anciens que la réplication de test sont retraités avec chaque réplication inverse. Si de tels éléments existent déjà dans la file d’attente, ils peuvent être recherchés avec la requête XPath JCR suivante et doivent être supprimés. /jcr:root/var/replication/outbox//*[@cq:repActionType='TEST']
Again you can develop a solution to detect all replication agents (located under /etc/replication/author or /etc/replication/publish ), then check the status of the agent ( enabled , disabled ) and the underlying queue ( active , idle , blocked ).

Surveillance de la performance

L’optimisation de la performance est un processus interactif bénéficiant d’une attention particulière pendant le développement. Après le déploiement, ce point est généralement révisé à intervalle régulier ou après des événements spécifiques.
Les méthodes utilisées lors de la collecte des informations pour le ciblage peuvent également être utilisées pour une surveillance continue.
Les configurations spécifiques disponibles pour améliorer la performance peuvent également être vérifiées.
Vous trouverez ci-après une liste des problèmes de performance qui surviennent de temps à autre, ainsi que des solutions potentielles sur la façon de les repérer et de les résoudre.
Domaine
Symptôme(s)
Pour augmenter la capacité…
Pour réduire le volume...
Client
Usage processeur intensif du client.
Installez un processeur client avec de meilleures performances.
Simplifiez la mise en page (HTML).
Faible usage du processeur de serveur.
Effectuez une mise à jour vers un navigateur plus rapide.
Améliorez le cache côté client.
Certains clients rapides, d’autres lents.
Serveur
Réseau
Faible usage du processeur sur les serveurs et les clients.
Supprimez tous les goulets d’étranglement du réseau.
Améliorez/optimisez la configuration du cache client.
La navigation en local sur le serveur est rapide (en comparaison).
Augmentez la bande passante du réseau.
Réduisez le « poids » de vos pages web (par exemple moins d’images, HTML optimisé).
Serveur web
Usage élevé du processeur sur le serveur web.
Mettez vos serveurs web en cluster.
Réduisez le nombre d’accès par page (visite).
Utilisez un équilibreur de charge matériel.
Application
Usage élevé du processeur du serveur.
Mettez vos instances AEM en cluster.
Recherchez, et éliminez les monopoles de processeur et de mémoire (utiliser la révision du code, la sortie d’expiration, etc).
Consommation de mémoire élevée.
Améliorez la mise en cache à tous les niveaux.
Faibles délais de réponse.
Optimisez les modèles et les composants (par exemple la structure, la logique).
Référentiel
Cache
Des problèmes de performances peuvent être causés par des éléments qui n’ont rien à voir avec votre site web, y compris des ralentissements temporaires de la vitesse de connexion, le chargement du processeur, et bien plus encore.
Cela peut également impacter tous vos visiteurs, ou uniquement un partie d’entre eux.
Toutes ces informations doivent être obtenues, classées et analysées avant que vous ne puissiez optimiser la performance générale ou résoudre des problèmes spécifiques.
  • Avant d’être confronté à des problèmes de performance :
    • Collectez autant d’informations que possible afin d’avoir une bonne maîtrise du système dans des circonstances normales.
  • Lorsque vous êtes confronté à un problème de performance :
    • Essayez de le répliquer avec un navigateur web standard (de préférence plusieurs), sur un autre client qui dispose d’une bonne performance générale et/ou sur le serveur lui-même (si possible)
    • Vérifiez si un élément (associé au système) a récemment changé, et si ces modifications n’ont pas affecté la performance
    • Posez-vous des questions telles que :
      • Ce problème arrive-t-il à des moments spécifiques ?
      • Se reproduit-t-il uniquement sur des pages spécifiques ?
      • D’autres demandes sont-elles impactées ?
    • Collectez autant d’informations que possible à comparer à votre connaissance du système dans des circonstances normales :

Outils pour surveiller et analyser les performances

Les sections suivantes vous offrent un bref aperçu des outils disponibles pour surveiller et analyser les performances.
Certains d’entre eux varient en fonction de votre système d’exploitation.
Outil Utilisé pour analyser… Utilisation/plus d’informations…
request.log Les temps de réponse et la simultanéité. Interprétation de request.log .
truss/strace Chargements de page
Commandes Unix/Linux pour tracer les appels et les signaux du système. Augmentez le niveau de journalisation sur INFO .
Analysez le nombre de chargements de pages par demande, quelles pages, etc.
Images mémoire de threads Observez les threads JVM. Identifiez les contentions, les verrouillages et les exécutions longues.
Dependent on the operating system: - Unix/Linux: kill -QUIT < pid > - Windows (console mode): Ctrl-Break
Des outils d’analyse sont disponibles, tels que TDA .
Vidages de tas Problèmes d’insuffisance de mémoire affectant la vitesse de performance.
Add the: -XX:+HeapDumpOnOutOfMemoryError option to the java call to AEM.
Appels système Identifier les problèmes de durée.
Calls to System.currentTimeMillis() or com.day.util .Timing are used to generate timestamps from your code, or via HTML-comments .
Remarque : ils doivent être mis en place afin de pouvoir être activés/désactivés si nécessaire. Lorsqu’un système fonctionne parfaitement, il n’est pas nécessaire de perdre du temps à collecter des statistiques.
Apache Bench Identifier les fuites de mémoire, analyser les temps de réponse de manière sélective.
L’utilisation de base est :
ab -k -n < requests > -c < concurrency > < url >
See Apache Bench and the ab man page for full details.
Analyse de la recherche Exécuter les recherches hors ligne, identifier le délai de réponse de la demande, tester et confirmer les résultats.
JMeter Tests de chargement et tests fonctionnels. https://jakarta.apache.org/jmeter/
JProfiler Profilage complet du processeur et de la mémoire. https://www.ej-technologies.com/
JConsole Observer les threads et les métriques JVM.
Utilisation : jconsole
Remarque : avec JDK 1.6, JConsole est extensible avec des modules complémentaires ; par exemple, Top ou TDA (Thread Dump Analyzer).
Java VisualVM Observer les métriques, les threads, la mémoire et le profilage JVM.
Utilisation : jvisualvm ou visualvm
Remarque : avec JDK 1.6, VisualVM est extensible avec des modules complémentaires.
truss/strace, lsof Appel du noyau en profondeur et analyse des processus (Unix). Commandes Unix/Linux.
Statistiques de durée Voir les statistiques de durée pour le rendu de page.
To see timing statistics for page rendering you can use Ctrl-Shift-U together with ?debugClientLibs=true set in the URL.
Outil de profilage du processeur et de la mémoire Utilisé pour l’analyse des demandes lentes pendant le développement. . Par exemple, YourKit .
Collecte des informations L’état actuel de votre installation. Apprendre le plus possible sur votre installation peut également vous aider à détecter ce qui a pu causer un changement au niveau de la performance et si ces changements sont justifiés. Ces informations doivent être collectées de façon régulière, afin que vous puissiez facilement identifier des modifications importantes.

Interprétation de request.log

Ce fichier permet d’enregistrer des données de base sur chaque demande envoyée à AEM. Vous pouvez en tirer des conclusions précieuses.
request.log fournit une méthode intégrée pour identifier la durée des demandes. For development purposes it is useful to tail -f the request.log and watch for slow response times. Pour analyser un fichier request.log de plus grande envergure, nous vous recommandons l’utilisation de .
Nous vous recommandons d’isoler les pages « lentes » de request.log , puis de les régler individuellement pour une meilleure performance. Cette opération est généralement effectuée en incorporant des mesures de performance par composant, ou en utilisant un outil de profilage des performances tel que [yourkit](https://www.yourkit.com/) .

Surveillance du trafic sur votre site web

Le journal des demandes permet d’enregistrer chaque demande effectuée, ainsi que la réponse donnée :
09:43:41 [66] -> GET /author/y.html HTTP/1.1
09:43:41 [66] <- 200 text/html 797ms

En totalisant toutes les entrées GET d’une période spécifique (par exemple plus de 24 heures), vous pouvez informer sur le temps moyen passé sur votre site web.

Surveillance des délais de réponse avec request.log

Le journal des demande est un point de départ intéressant pour l’analyse de performances :
<*cq-installation-dir*>/crx-quickstart/logs/request.log
Le journal se présente comme suit (les lignes sont raccourcis pour plus de simplificité) :
31/Mar/2009:11:32:57 +0200 [379] -> GET /path/x HTTP/1.1
31/Mar/2009:11:32:57 +0200 [379] <- 200 text/html 33ms
31/Mar/2009:11:33:17 +0200 [380] -> GET /path/y HTTP/1.1
31/Mar/2009:11:33:17 +0200 [380] <- 200 application/json 39ms

Ce journal dispose d’une ligne par requête ou réponse :
  • La date à laquelle chaque requête ou réponse a été effectuée.
  • Le nombre de requêtes, entre crochets. Ce numéro correspond à la requête et à la réponse.
  • Une flèche indiquant s’il s’agit d’une requête (flèche vers la droite) ou d’une réponse (flèche vers la gauche).
  • Pour les demandes, la ligne contient :
    • la méthode (généralement, GET, HEAD ou POST)
    • la page demandée
    • le protocole
  • Pour les réponses, la ligne contient :
    • le code d’état (200 signifie « réussite », 404 signifie « page non trouvée »
    • le type MIME
    • le temps de réponse
L’utilisation de petits scripts vous permet d’extraire les informations requises du fichier journal et de compiler les statistiques de votre choix. Par ailleurs, vous pouvez voir quelles pages ou quels types de pages sont lents et si la performance générale est satisfaisante.

Surveillance des temps de réponse de la recherche avec request.log

Les requêtes de recherche sont également enregistrées dans le fichier journal :
31/Mar/2009:11:35:34 +0200 [338] -> GET /author/playground/en/tools/search.html?query=dilbert&size=5&dispenc=utf-8 HTTP/1.1
31/Mar/2009:11:35:34 +0200 [338] <- 200 text/html 1562ms

Par conséquent, comme indiqué ci-dessus, vous pouvez utiliser des scripts pour extraire les informations nécessaires et établir des statistiques.
Toutefois, une fois que vous avez déterminé le délai de réponse, vous pourriez avoir besoin d’analyser pourquoi la requête prend autant temps et de déterminer les mesures à prendre pour améliorer la réponse.

Surveillance du nombre et de l’impact des utilisateurs simultanés

request.log peut encore être utilisé pour surveiller les accès simultanés et la réaction du système.
Des tests doivent être effectués pour déterminer le nombre d’utilisations simultanées pouvant être traitées par le système avant qu’il n y ait un impact négatif. Des scripts peuvent encore être utilisés pour extraire les résultats du fichier journal :
  • Surveillez le nombre de demandes effectuées dans un certain laps de temps, par exemple une minute
  • Testez l’impact d’un certain nombre d’utilisateurs effectuant tous les mêmes demandes (aussi proches que possible) au même moment, par exemple 30 utilisateurs cliquant sur Enregistrer en même temps.
31/Mar/2009:11:45:29 +0200 [333] -> GET /author/libs/Personalize/content/statics.close.gif HTTP/1.1
31/Mar/2009:11:45:29 +0200 [334] -> GET /author/libs/Personalize/content/statics.detach.gif HTTP/1.1
31/Mar/2009:11:45:30 +0200 [335] -> GET /author/libs/CFC/content/imgs/logo.rZMNURccynWcTpCxyuBNiTCoiBMmw000.default.gif HTTP/1.1
31/Mar/2009:11:45:32 +0200 [335] <- 304 text/html 0ms
31/Mar/2009:11:45:33 +0200 [334] <- 200 image/gif 31ms
31/Mar/2009:11:45:38 +0200 [333] <- 200 image/gif 31ms
31/Mar/2009:11:45:42 +0200 [336] -> GET /author/libs/CFC/content/imgs/logo.rZMNURccynWcTZRXunQbbQtvuuCMbRRBuWXz0000.default.gif HTTP/1.1
31/Mar/2009:11:45:43 +0200 [337] -> GET /author/titlebar_bg.gif HTTP/1.1
31/Mar/2009:11:45:43 +0200 [336] <- 304 text/html 0ms
31/Mar/2009:11:45:44 +0200 [337] <- 304 text/html 0ms

Utilisation de rlog.jar pour trouver des demandes avec de longues durées

AEM includes various helper tools located in: <*cq-installation-dir*>/crx-quickstart/opt/helpers
L’un de ces outils, rlog.jar , , peut être utilisé pour trier rapidement request.log de sorte que les demandes soient affichées selon la durée, c’est-à-dire de la plus longue à la plus courte.
La commande suivante affiche les arguments possibles :
$java -jar rlog.jar
Request Log Analyzer Version 21584 Copyright 2005 Day Management AG
Usage:
  java -jar rlog.jar [options] <filename>
Options:
  -h               Prints this usage.
  -n <maxResults>  Limits output to <maxResults> lines.
  -m <maxRequests> Limits input to <maxRequest> requests.
  -xdev            Exclude POST request to CRXDE.

Par exemple, vous pouvez l’exécuter en spécifiant le fichier request.log en tant que paramètre et afficher les 10 premières demandes ayant la plus longue durée :
$ java -jar ../opt/helpers/rlog.jar -n 10 request.log
*Info * Parsed 464 requests.
*Info * Time for parsing: 22ms
*Info * Time for sorting: 2ms
*Info * Total Memory: 1mb
*Info * Free Memory: 1mb
*Info * Used Memory: 0mb
------------------------------------------------------
     18051ms 31/Mar/2009:11:15:34 +0200 200 GET /content/geometrixx/en/company.html text/ html
      2198ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/cq/widgets.js application/x-javascript
      1981ms 31/Mar/2009:11:15:11 +0200 200 GET /libs/wcm/content/welcome.html text/html
      1973ms 31/Mar/2009:11:15:52 +0200 200 GET /content/campaigns/geometrixx.teasers..html text/html
      1883ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/security/cq-security.js application/x-javascript
      1876ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/tagging/widgets.js application/x-javascript
      1869ms 31/Mar/2009:11:15:20 +0200 200 GET /libs/tagging/widgets/themes/default.js application/x-javascript
      1729ms 30/Mar/2009:16:45:56 +0200 200 GET /libs/wcm/content/welcome.html text/html; charset=utf-8
      1510ms 31/Mar/2009:11:15:34 +0200 200 GET /bin/wcm/contentfinder/asset/view.json/ content/dam?_dc=1238490934657&query=&mimeType=image&_charset_=utf-8 application/json
      1462ms 30/Mar/2009:17:23:08 +0200 200 GET /libs/wcm/content/welcome.html text/html; charset=utf-8

Vous pouvez avoir à concaténer les différents fichiers request.log si vous devez effectuer cette opération sur un grand échantillon de données.

Apache Bench

Pour minimiser l’impact des cas particuliers (tels que le nettoyage, etc.), il est recommandé d’utiliser un outil tel que apachebench (voir par exemple ab pour obtenir plus d’informations) pour vous aider à identifier les fuites de mémoire et à analyser de manière sélective le délai de réponse.
Apache Bench peut être utilisé de la manière suivante :
$ ab -c 5 -k -n 1000 "https://localhost:4503/content/geometrixx/en/company.html"
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, https://www.zeustech.net/
Licensed to The Apache Software Foundation, https://www.apache.org/

Benchmarking localhost (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests

Server Software: Day-Servlet-Engine/4.1.52
Server Hostname: localhost
Server Port: 4503

Document Path: /content/geometrixx/en/company.html
Document Length: 24127 bytes

Concurrency Level: 5
Time taken for tests: 69.766 seconds
Complete requests: 1000
Failed requests: 998
(Connect: 0, Receive: 0, Length: 998, Exceptions: 0)
Write errors: 0
Keep-Alive requests: 0
Total transferred: 24160923 bytes
HTML transferred: 24010923 bytes
Requests per second: 14.33 /sec (mean)
Time per request: 348.828 [ms] (mean)
Time per request: 69.766 [ms] (mean, across all concurrent requests)
Transfer rate: 338.20 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 1 3.9 0 58
Processing: 138 347 568.5 282 8106
Waiting: 137 344 568.1 281 8106
Total: 139 348 568.4 283 8106

Percentage of the requests served within a certain time (ms)
50% 283
66% 323
75% 356
80% 374
90% 439
95% 512
98% 1047
99% 1132
100% 8106 (longest request)

Les chiffres ci-dessus sont extraits d’un ordinateur portable standard MacBook Pro (mi-2010) avec accès à la page d’entreprise geometrixx, comme inclus dans une installation d’AEM par défaut. La page est très simple, mais non optimisée pour la performance.
apachebench affiche également le temps par requête comme moyenne, pour toutes les requêtes simultanées ; voir Time per request: 54.595 [ms] (moyenne, pour toutes les demandes simultanées). You can change the value of the concurrency parameter -c (number of multiple requests to perform at a time) to see any effects.

Compteurs de demandes

Les informations sur le trafic de demandes (nombre de demandes au cours d’une période déterminée) vous donnent une indication du chargement de votre instance. Ces informations peuvent être extraites de request.log à l’aide des compteurs, automatisant ainsi la collecte de données pour vous permettre de constater :
  • les différences considérables d’activité (c’est-à-dire la différence entre « nombreuses demandes » et « faible activité »
  • lorsqu’une instance n’est pas en cours d’utilisation
  • chaque redémarrage (les compteurs sont réinitialisés à 0)
Pour automatiser la collecte des informations, vous pouvez également installer un RequestFilter (filtre de demandes) pour compter chaque demande de manière incrémentale. Plusieurs compteurs peuvent être utilisés pour des périodes différentes.
Les informations collectées peuvent être utilisées pour indiquer :
  • les changements importants de l’activité
  • une instance redondante
  • chaque redémarrage (le compteur est réinitialisé à 0)

Commentaires HTML

It is recommended that every project includes html comments for server performance. Vous pouvez trouver de nombreux exemples pertinents dans la sphère publique ; sélectionnez une page, ouvrez la source de la page pour l’afficher, faites-la ensuite défiler vers le bas, et le code suivant peut ensuite être consulté :
</body>
 </html>
        <!--
        Page took 58 milliseconds to be rendered by server
         -->

Surveillance de la performance à l’aide JConsole

La commande d’outil jconsole est disponible avec JDK.
  1. Démarrez votre instance AEM.
  2. Exécuter jconsole.
  3. Sélectionnez votre instance AEM et connectez-vous .
  4. From within the Local application, double-click com.day.crx.quickstart.Main ; the Overview will be shown as default:
    Après cela, vous pouvez sélectionner d’autres options.

Surveillance de la performance à l’aide de (J)VisualVM

Depuis JDK 1.6, la commande d’outil jvisualvm est disponible. Une fois que vous avez installé JDK 1.6, vous pouvez :
  1. Démarrez votre instance AEM.
    If using Java 5 you can add the -Dcom.sun.management.jmxremote argument to the java command line that starts your JVM. JMX est activé par défaut avec Java 6.
  2. Exécutez l’une des deux options suivantes :
    • jvisualvm  : dans le dossier bin JDK 1.6 (version testée)
    • visualvm  : peut être téléchargé à partir de VisualVM (la version la plus à la pointe)
  3. From within the Local application, double-click com.day.crx.quickstart.Main ; the Overview will be shown as default:
    Après cela, vous pouvez sélectionner d’autres options, y compris le moniteur :
Vous pouvez utiliser cet outil pour générer des images mémoire de threads et des images mémoire d’en-tête. Ces informations sont souvent demandées par l’équipe technique.

Collecte des informations

Une connaissance approfondie de votre installation peut vous aider à déterminer ce qui a pu causer un changement de performance et si ces changements sont justifiés. Ces informations doivent être collectées de façon régulière, afin que vous puissiez facilement identifier des modifications importantes.
Les informations suivantes peuvent s’avérer utiles :

Combien d’auteurs travaillent avec le système ?

Pour afficher le nombre d’auteurs qui ont utilisé le système depuis l’installation, utilisez la ligne de commande :
cd <cq-installation-dir>/crx-quickstart/logs
cut -d " " -f 3 access.log | sort -u | wc -l

Pour afficher le nombre d’auteurs à une date spécifique :
grep "<date>" access.log | cut -d " " -f 3 | sort -u | wc -l

Quel est le nombre moyen d’activations de page par jour ?

Pour voir nombre total d’activation de page depuis l’installation du serveur, utilisez une requête de référentiel ; via CRXDE - Outils - Requête :
  • Type XPath
  • Chemin /
  • Query //element(*, cq:AuditEvent)[@cq:type='Activate']
Calculez ensuite le nombre de jours écoulés depuis l’installation pour calculer la moyenne.

Combien de pages maintenez-vous actuellement sur ce système ?

Pour voir nombre de pages actuellement sur le serveur, utilisez une requête de référentiel ; via CRXDE- outils- requête :
  • Type XPath
  • Chemin /
  • Query //element(*, cq:Page)

Si vous utilisez MSM, quel est le nombre moyen de déploiements par mois ?

Pour déterminer le nombre total de déploiements depuis l’installation, utilisez une requête de référentiel ; via CRXDE - Outils - Requête :
  • Type XPath
  • Chemin /
  • Query //element(*, cq:AuditEvent)[@cq:type='PageRolledOut']
Calculez le nombre de mois écoulés depuis l’installation pour calculer la moyenne.

Quel est le nombre moyen de Live Copies par mois ?

Pour déterminer le nombre total des Live Copies effectuées depuis l’installation utilisent une requête de référentiel ; via CRXDE- outils- requête :
  • Type XPath
  • Chemin /
  • Query //element(*, cq:LiveSyncConfig)
Utilisez toujours le nombre de mois écoulés depuis l’installation pour calculer la moyenne.

Si vous utilisez AEM Assets, combien de ressources y maintenez-vous actuellement ?

Pour voir le nombre de ressource de gestion des actifs numériques que vous conservez actuellement, utilisez une requête de référentiel ; via CRXDE - Outils - Requête :
  • Type XPath
  • Chemin /
  • Query /jcr:root/content/dam//element(*, dam:Asset)

Quelle est la taille moyenne des ressources ?

To determine the total size of the /var/dam folder:
  1. Utilisez WebDAV pour mapper le référentiel dans le système de fichiers local.
  2. Utilisez la ligne de commande :
    cd /Volumes/localhost/var
    du -sh dam/
    
    
    To get the average size, divide the global size by the total number of assets in /var/dam (obtained above).

Combien de modèles sont actuellement utilisés ?

Pour identifier le nombre de modèles actuellement sur le serveur, utilisez une requête de référentiel ; via CRXDE - Outils - Requête :
  • Type XPath
  • Chemin /
  • Query //element(*, cq:Template)

Combien de composants sont actuellement utilisés ?

Pour voir nombre de composants actuellement sur le serveur, utilisez une requête de référentiel ; via CRXDE - Outils - Requête :
  • Type XPath
  • Chemin /
  • Query //element(*, cq:Component)

Combien de demandes par heure recevez-vous sur le système de création lorsque le niveau d’activité est élevé ?

Pour déterminer le nombre de demandes par heure que vous recevez sur le système de création lorsque le niveau d’activité est élevé :
  1. Pour déterminer le nombre total de demandes depuis l’installation, utilisez la ligne de commande :
    cd <cq-installation-dir>/crx-quickstart/logs
    grep -R "\->" request.log | wc -l
    
    
  2. Pour déterminer les dates de début et de fin :
    vim request.log
    G / 1G: for the last/first lines
    
    
    Utilisez ces valeurs pour calculer le nombre d’heures qui se sont écoulées depuis l’installation, puis le nombre moyen de demandes par heure.

Combien de demandes par heure recevez-vous sur le système de publication lorsque le niveau d’activité est élevé ?

Répétez la procédure ci-dessus sur votre instance de publication.

Analyse de scénarios spécifiques

Voici une liste de suggestions des éléments à vérifier si vous commencez à rencontrer certains problèmes de performance. La liste n’est (malheureusement) pas tout à fait complète.

Processeur à 100 %

Si le processeur de votre système fonctionne en permanence à 100 %, voir :

Mémoire insuffisante

Bien que ces erreurs doivent être détectées au cours du développement et des tests, certains scénarios peuvent vous échapper.
Si votre système ne dispose pas de suffisamment de mémoire, cela peut vous être signalé de différentes façons, notamment une détérioration des performances et des messages d’erreur comprenant le sous-texte :
java.lang.OutOfMemoryError
Dans ce cas, vérifiez :

I/O des disques

Si votre système ne dispose pas de suffisamment d’espace de disque ou que le disque est en train de se détériorer, commencez par voir :

Détérioriation régulière des performances

Si vous voyez la performance de votre instance se détériorer après chaque réinitialisation (parfois après une semaine ou plus), ce qui suit peut être vérifié :

Réglage de JVM

La capacité de réglage de Java Virtual Machine (JVM) a été considérablement améliorée (surtout depuis Java 7). Pour cette raison, la spécification d’une taille fixe raisonnable de JVM et l’utilisation des paramètres par défaut sera souvent convenable.
Si les paramètres par défaut ne sont pas adéquats, il est important de créer une méthode pour surveiller et évaluer la performance de GC avant de tenter d’effectuer un réglage de JVM ; cela peut impliquer de surveiller des facteurs comme la taille du tas, l’algorithme et d’autres aspects.
Autres options courantes :
  • VerboseGC :
    -verbose:gc \
     -Xloggc:$LOGS/verbosegc.log \
     -XX:+PrintGCDetails \
     -XX:+PrintGCDateStamps
    
    
Le rapport résultant peut être assimilé par un visualiseur GC comme :
[https://www.ibm.com/developerworks/library/j-ibmtools2/](https://www.ibm.com/developerworks/library/j-ibmtools2/)
Ou JConsole :
  • Ces paramètres sont destinés à une connexion JMX "large ouverte" :
    -Dcom.sun.management.jmxremote \
     -Dcom.sun.management.jmxremote.port=8889 \
     -Dcom.sun.management.jmxremote.authenticate=false \
     -Dcom.sun.management.jmxremote.ssl=false
    
    
  • Connectez-vous ensuite à la JVM avec la console JConsole ; voir: [https://docs.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html](https://docs.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html)
Cela vous aidera à déterminer la quantité de mémoire utilisée, les algorithmes GC utilisés, leur durée d’exécution et l’impact sur la performance de l’application. Sans cela, le réglage n'est que des "boutons de redéfinition aléatoire".
Pour la machine virtuelle d’Oracle, il existe également des informations à l’adresse suivante : https://docs.oracle.com/javase/7/docs/technotes/guides/vm/server-class.html