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.	Les messages « *ERROR* LowDiskSpaceBlocker » 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.
Les performances d’AEM sont surveillées.	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.	Voir Purge régulière des instances de workflow.

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

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. Sauvegardez l’intégralité du fichier <cq-installation-dir> depuis votre système de fichiers.

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 début Un 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 des données, vous pouvez choisir d’effectuer une opération sur un nœud ou sur une hiérarchie complète en choisissant Récursif. Dans ce cas, le chemin donné définit le nœud racine de la hiérarchie.

Versions maximales à conserver Nombre maximal de versions à conserver pour un nœud. Lorsque ce nombre dépasse la valeur, les versions les plus anciennes sont purgées.

Âge de version maximal L’âge maximal de la version d’un nœud. Lorsque l’âge d’une version dépasse cette valeur, elle est purgée.

Exécution d’essai Étant donné que la suppression des versions de contenu est définitive et ne peut pas être rétablie sans la restauration d’une sauvegarde, l’outil Purge de versions fournit un mode Exécution d’essai qui permet d’afficher un aperçu des versions purgées. Pour lancer le mode Exécution d’essai du processus de purge, cliquez sur Exécution d’essai.

Purge Lancez la purge des versions sur le nœud défini par le chemin de début.

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. Définissez le chemin de début du contenu à purger (par exemple /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.

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 statuts suivants :

• ignore (not versionnable) : le nœud ne prend pas en charge les versions et est ignoré lors du processus.
• ignore (no version) : le nœud n’a pas de version et est ignoré lors du processus.
• retained : le nœud n’est pas purgé.
• purged : le nœud est purgé.

Par ailleurs, la console affiche des informations utiles sur les versions :

• V 1.0 : le numéro de version.
• V 1.0.1* : l’étoile indique que la version est la version actuelle.
• Thu Mar 15 2012 08:37:32 GMT+0100 : la 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.
• Les versions Tonga Fashions! sont purgées, car le nombre de versions est supérieur à 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 {original_filename} .yyyy-MM-dd. Par exemple, le 11 juillet 2010, le fichier journal actuel est renommé error.log-2010-07-10, puis un nouveau fichier error.og est créé.
• Les fichiers journaux précédents ne sont pas supprimés. Il est de votre responsabilité de nettoyer régulièrement les anciens fichiers journaux pour limiter l’utilisation du disque.

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 propose des statistiques et des informations d’analyse utilisées pour analyser le comportement du processus interne d’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é. Le journal s7access enregistre chaque demande envoyée à Dynamic Media via /is/image et /is/content.

  • stderr.log

    Contient les messages d’erreur, de différents niveaux de gravité, générés lors du démarrage. Par défaut, le niveau de journalisation est défini sur 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 de la variable com.day.compat.codeupgrade et com.adobe.cq.upgradesexecutor modules.

• <cq-installation-dir>/crx-quickstart/repository

  • revision.log

    Informations sur la journalisation des révisions.

Activation du niveau de journalisation DÉBOGUER

Le niveau de journalisation par défaut Configuration de la journalisation Apache Sling est Informations. Par conséquent, les messages de débogage ne sont 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. Par exemple, sur /libs/sling/config/org.apache.sling.commons.log.LogManager pour configurer la journalisation globale Apache Sling.

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é

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. S’il n’existe pas déjà, créez un dossier de configuration (sling:Folder) pour votre projet /apps/<project-name>/config.

2. Sous /apps/<project-name>/config, créez un nœud pour la nouvelle configuration de l’enregistreur de journaux Apache Sling :

   • Nom :

   org.apache.sling.commons.log.LogManager.factory.config-<identifier> (car il s’agit d’un enregistreur)

   Où <identifier> est remplacé par du texte libre que vous devez entrer pour l’instance (vous ne pouvez pas omettre cette information). Par exemple, org.apache.sling.commons.log.LogManager.factory.config-MINE

   • Type : sling:OsgiConfig
   REMARQUE

   Bien que cela ne constitue pas une exigence technique, il est recommandé de rendre <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 : String[] (String + Multi)

     Valeur : spécifiez les services OSGi pour lequel l’enregistreur consigne les messages ; par exemple, tous les services suivants :

     • org.apache.sling
     • org.apache.felix
     • com.day

   • Nom : org.apache.sling.commons.log.level

     Type : chaîne

     Valeur : spécifiez le niveau de journalisation 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 : spécifier le modèle du message du journal, au besoin ; par exemple,

       {0,date,dd.MM.yyyy HH:mm:ss.SSS} *{4}* [{2}] {3} {5}

   REMARQUE

   org.apache.sling.commons.log.pattern prend en charge jusqu’à six arguments.

   {0} Horodatage de type java.util.Date

   {1} Le marqueur de journal

   {2} Le nom du thread actuel

   {3} Le nom de l’enregistreur

   {4} Le niveau de journalisation

   {5} Le message du journal

   Si l’appel de journal comprend un Throwable, la trace de pile est ajoutée au message.

   ATTENTION

   org.apache.sling.commons.log.names doit avoir une valeur.

   REMARQUE

   Les chemins du rédacteur de journalisation est relatif à l’emplacement crx-quickstart.

   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

   inscrit dans un répertoire :

   <cq-installation-dir>/logs/
   (soit à côté 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).

   ATTENTION

   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.

   Sous /apps/<project-name>/config, créez un nœud pour la nouvelle configuration de l’enregistreur de journaux Apache Sling :

   • Nom : org.apache.sling.commons.log.LogManager.factory.writer-<identifier> (s’agissant d’un rédacteur)

     Où <identifier> est remplacé par du texte libre que vous devez entrer pour l’instance (vous ne pouvez pas omettre cette information). Par exemple, org.apache.sling.commons.log.LogManager.factory.writer-MINE

   • Type : sling:OsgiConfig

   REMARQUE

   Bien que cela ne constitue pas une exigence technique, il est recommandé de rendre <identifier> unique.

   Définissez les propriétés suivantes sur ce nœud :

   • Nom : org.apache.sling.commons.log.file

     Type : String

     Valeur : indiquez le fichier journal afin qu’il corresponde au fichier spécifié dans l’enregistreur ;

     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

       Valeur : spécifiez le nombre de fichiers journaux que vous souhaitez conserver ; par exemple, 5.

     • Nom : org.apache.sling.commons.log.file.size

       Type : String

       Valeur : spécifiez-la comme nécessaire pour contrôler la rotation du fichier par taille/date ; par exemple, '.'yyyy-MM-dd.

   REMARQUE

   org.apache.sling.commons.log.file.size contrôle la rotation du fichier journal en fonction du paramètre :

   • de taille maximale de fichier
   • ou de 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. Si aucune unité de taille n’est donnée, il s’agit du nombre d’octets, ou vous pouvez ajouter l’une des unités de taille : KB, MB ou GB (la casse est ignorée).
   • Une planification heure/date peut être spécifiée sous la forme d’un motif 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 de 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 une version nouvelle et vide de …/logs/error.log 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 le premier jour de la semaine (dépend du paramètre régional)
   '.'yyyy-MM-dd	Rotation à minuit chaque jour
   '.'yyyy-MM-dd-a	Rotation à minuit et midi chaque jour
   '.'yyyy-MM-dd-HH	Rotation au début de chaque heure
   '.'yyyy-MM-dd-HH-mm	Rotation au début de chaque minute

   Remarque : Lorsque vous spécifiez une heure/date :

   1. vous devez placer le texte littéral « escape » dans une paire de guillemets simples (’ ’) ;

      cela permet d’éviter que certains caractères ne soient interprétés comme des lettres majuscules.

   2. 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é.

   Le fichier journal créé dans cet exemple sera ../crx-quickstart/logs/myLogFile.log.

La console Felix fournit également des informations sur la prise en charge du journal Sling à l’adresse ../system/console/slinglog ; par exemple, http://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

Dans le dossier /var/audit, les enregistrements d’audit sont conservés selon la ressource. 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

Les événements OSGi produisent également des enregistrements d’audit pouvant être affichés dans l’onglet Statut de la configuration -> Onglet Fichiers journaux dans la console web Adobe AEM :

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 ?

• toutes les files d’attente enabled doivent avoir le statut idle ou active, qui indiquent un fonctionnement normal ; aucune file d’attente ne doit être blocked, ce qui signale souvent des problèmes du côtés des destinataires.

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

   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']

Vous pouvez toujours développer une solution pour détecter tous les agents de réplication (situés sous /etc/replication/author ou /etc/replication/publish), puis vérifier le statut de l’agent (enabled, disabled) et de la file d’attente sous-jacente (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.

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 sont 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 de pouvoir 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.	En fonction du système d’exploitation : - Unix/Linux : kill -QUIT <pid> - Windows (mode console) : 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.	Ajoutez l’option : option -XX:+HeapDumpOnOutOfMemoryError vers l’appel Java à AEM. Voir le Guide de dépannage pour Java SE 6 avec HotSpot VM.
Appels système	Identifier les problèmes de durée.	Appels à System.currentTimeMillis() ou com.day.util. Les durées sont utilisées pour générer les horodatages à partir de votre code ou via les commentaires HTML. 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> Consultez Apache Bench et la page ab man pour plus de détails.
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 Voir jconsole et Surveillance de la performance en utilisant 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 Voir jvisualvm, visualvm et Surveillance de la performance à l’aide de (J)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.	Pour voir les statistiques de durée pour le rendu de page, vous pouvez utiliser Ctrl-Shift-U avec ?debugClientLibs=true défini dans l’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 changements importants.

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. Pour le développement, il est utile d’utiliser tail -f sur request.log et d’observer les temps de réponse lents. Pour analyser un fichier request.log de plus grande envergure, nous vous recommandons l’utilisation de rlog.jar, qui permet de trier et de filtrer les délais de réponse.

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 dans cette situation.

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 comprend divers outils d’assistance situés dans :

<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 "http://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. Cette page est très simple mais n’est pas optimisée en terme de performance.

apachebench affiche également la durée par demande comme la moyenne de toutes les requêtes simultanées ; ici Time per request: 54.595 [ms] (moyenne de toutes les requêtes simultanées). Vous pouvez modifier la valeur du paramètre d’accès simultané -c (nombre de demandes multiples à exécuter à un moment donné) pour voir si cela produit un effet.

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

Nous vous recommandons d’inclure des html comments sur la performance du serveur pour chaque projet. 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écutez jconsole..

3. Sélectionnez votre instance AEM et connectez-vous.

4. Depuis l’application Local, double-cliquez sur com.day.crx.quickstart.Main ; l’aperçu par défaut s’affiche :

   

   Après cela, vous pouvez sélectionner d’autres options.

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

Depuis le JDK 1.6, la commande d’outil jvisualvm est disponible. Une fois que vous avez installé le JDK 1.6. vous pouvez :

1. Démarrez votre instance AEM.

   REMARQUE

   Si vous utilisez Java 5, vous pouvez ajouter l’argument -Dcom.sun.management.jmxremote à la ligne de commande Java qui permet de lancer votre 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. Depuis l’application Local, double-cliquez sur com.day.crx.quickstart.Main ; l’aperçu par défaut s’affiche :

   

   Après cela, vous pouvez sélectionner d’autres options, y compris 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 changements importants.

Les informations suivantes peuvent s’avérer utiles :

• Combien d’auteurs travaillent avec le système ?
• Quel est le nombre moyen d’activations de page par jour ?
• Combien de pages maintenez-vous actuellement sur ce système ?
• Si vous utilisez MSM, quel est le nombre moyen de rollouts par mois ?
• Quel est le nombre moyen de Live Copies par mois ?
• Si vous utilisez AEM Assets, combien de ressources maintenez-vous actuellement ?
• Quelle est la taille moyenne des ressources ?
• Combien de modèles sont actuellement utilisés ?
• Combien de composants sont actuellement utilisés ?
• Combien de demandes par heure recevez-vous sur le système de création lorsque le niveau d’activité est élevé ?
• Combien de demandes par heure recevez-vous sur le système de publication lorsque le niveau d’activité est élevé ?

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 /

• Requête //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 /

• Requête //element(*, cq:Page)

Si vous utilisez MSM, quel est le nombre moyen de rollouts 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 /

• Requête //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 /

• Requête //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 maintenez-vous actuellement ?

Pour voir le nombre de ressource de gestion des ressources numériques que vous conservez actuellement, utilisez une requête de référentiel ; via CRXDE - Outils - Requête :

• Type XPath

• Chemin /

• Requête /jcr:root/content/dam//element(*, dam:Asset)

Quelle est la taille moyenne des ressources ?

Pour déterminer la taille totale du dossier /var/dam :

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/
   

   Pour obtenir la taille moyenne, divisez la taille globale par le nombre total de ressources dans /var/dam (obtenu ci-dessus).

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 /

• Requête //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 /

• Requête //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 :

• La base de connaissances :

  • Analyse des processus lents et bloqués

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 les éléments suivants :

• les paramètres JVM utilisés pour lancer AEM

• La base de connaissances :

  • Analyse des problèmes de mémoire

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 :

• Si vous avez désactivé la collecte d’informations de débogage ; elle peut être configurée dans divers emplacements, y compris :

  • Gestionnaire de script JSP Apache Sling
  • Gestionnaire de script Java Apache Sling
  • Configuration de journalisation Apache Sling
  • Gestionnaire de bibliothèques HTML CQ
  • Filtre de débogage de la gestion du contenu web CQ
  • Enregistreurs

• Si et comment vous avez configuré la purge de version

• La base de connaissances :

  • Trop de fichiers ouverts
  • Le journal consomme trop d’espace disque

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é :

• Mémoire insuffisante

• La base de connaissances :

  • Sessions non fermées

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 concernent une connexion « très ouverte » de JMX :

  -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 à JVM avec la JConsole :
  [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 consiste simplement à manipuler des boutons de façon aléatoire.