Utilité de Request Metrics

Request metrics est un outil qui vous permet de suivre les transactions individuelles, en enregistrant le temps de traitement dans chacune des principales WebSphere® Application Server Composants.

Avant de commencer

Les informations suivies peuvent être sauvegardées dans le fichier journal pour analyse ultérieure et/ou envoyées à des agents ARM.

Lors du déroulement d'une transaction, Request Metrics enregistre des informations supplémentaires de sorte que les enregistrements de journal peuvent être mis en corrélation, ce qui constitue alors une image complète de cette transaction. On obtient un résultat similaire :

HTTP request/trade/scenario ------------------------------> 172 ms
     Servlet/trade/scenario  -----------------------------> 130 ms
         EJB TradeEJB.getAccountData --------------------->  38 ms
              JDBC select -------------------------------->   7 ms

Ce flux de transaction et les temps de réponse associés permettent de cerner les incidents de performances et de déboguer les contraintes de ressources. Par exemple, le flux permet de déterminer si une transaction s'exécute surtout dans le plug-in du serveur Web, le conteneur Web, le conteneur EJB ou la base de données dorsale. Le temps de réponse collecté pour chaque niveau comprend le temps passé à ce niveau et le temps passé aux niveaux inférieurs. Par exemple, le temps de réponse du servlet, qui est de 130 millisecondes, inclut également 38 millisecondes provenant des beans entreprise et de la connectivité de base de données Java™. Par conséquence, 92 millisecondes peuvent être attribués au processus du servlet.

Les mesures de demandes assurent le suivi du temps de réponse d'une transaction particulière. Du fait que Request Metrics assure le suivi de transactions individuelles, son utilisation exige de tenir d'un certain nombre de facteurs de performances sur le système. Cependant, cette fonction peut être mitigée par l'utilisation de fonctions de filtrage des demandes.

Par exemple, des outils peuvent injecter des transactions synthétiques. Les métriques de demande peuvent ensuite suivre le temps de réponse dans le délai WebSphere Application Server environnement pour ces transactions. Une transaction est synthétique quand elle est injectée dans le système par un administrateur afin de tester de façon proactive les performances de celui-ci. A l'aide de ces informations, l'administrateur optimise les performances du site Web et prend des mesures correctives. Par conséquent, les informations fournies par Request Metrics peuvent être employées comme mécanisme d'alerte qui se déclenche quand les performances d'un type de demande précis descendent sous des seuils acceptables. Il est possible d'utiliser le mécanisme de filtrage de Request Metrics afin de mettre l'accent sur les transactions synthétiques et d'optimiser les performances dans ce scénario.

A propos de cette tâche

Quand vous avez localisé les zones posant problème, vous pouvez les examiner à l'aide du mécanisme de filtrage Request Metrics. Par exemple, quand vous avez isolé un incident sur un servlet ou une méthode EJB, activez l'instrumentation sur cette ressource uniquement en utilisant des algorithmes URI ou un filtre EJB. Ce mécanisme de filtrage permet une analyse de performances plus précise.

Cinq types de filtres sont pris en charge :

Filtre IP source
Filtre URI
Filtre nom de méthode EJB
Filtre des paramètres JMS
Filtre des paramètres des services Web

Quand le filtrage est actif, seules les demandes correspondant au filtre génèrent des données Request Metrics, créent des enregistrements de journal et/ou appellent les interfaces ARM. Vous pouvez insérer un travail dans un système opérationnel (afin de générer des informations de trace)et, par là même, d'évaluer les performances de types de demandes précis dans des conditions de charge normale sans tenir compte des demandes émanant d'autres sources susceptibles d'affecter le système.

Note: Les filtres ne sont applicables que là où la demande entre en premier WebSphere Application Server.

Procédure

Pour plus de détails sur Request Metrics, reportez-vous à cette section.
Configurer et activer Request Metrics.
Récupérer les données de performance et surveiller le flux d'applications.
Etendre la surveillance pour suivre les applications qui peuvent avoir besoin de points d'instrumentation supplémentaires.

Exemple

Consultez l'exemple suivant pour apprendre à utiliser Request Metrics.

Dans cet exemple, le servlet HitCount et le bean enterprise Increment sont déployés sur deux processus de serveur d'applications différents. Comme le montre l'illustration suivante, le niveau conteneur Web et le niveau conteneur d'EJB (Entreprise JavaBeans) s'exécutent dans deux serveurs d'applications différents. Pour mettre en place une telle configuration, installez WebSphere Application Server Network Deployment.

Supposons que le serveur Web et le niveau conteneur Web s'exécutent tous deux sur la machine 192.168.0.1 et que le niveau conteneur d'EJB s'exécute sur une deuxième machine, 192.168.0.2. Les demandes du client peuvent être envoyées à partir d'une machine différente ; 192.168.0.3, par exemple, ou d'autres machines.

Pour illustrer l'utilisation du filtrage des adresses IP source, un filtre IP source (192.168.0.3) est défini et activé. Vous pouvez suivre les demandes provenant de la machine 192.168.0.3 via l'adresse http://192.168.0.1/hitcount?selection=EJB&lookup=GBL&trans=CMT. Toutefois, le suivi des demandes provenant d'autres machines n'est pas effectué car l'adresse IP source ne se trouve pas dans la liste des filtres.

Grâce à la seule création d'un filtre IP source, les demandes provenant de cette adresse IP source sont suivies efficacement. Cet outil est efficace pour localiser les problèmes de performance sur des systèmes soumis à une charge. Si la charge normale provient d'autres adresses IP, le suivi de ses demandes n'est pas effectué. En utilisant l'adresse IP source définie pour générer des demandes, vous pouvez voir les goulots d'étranglement des performances sur les divers sauts en comparant les enregistrements de trace du système chargé avec ceux provenant d'une exécution non chargée. Cette possibilité vous aide à concentrer vos efforts sur le noeud et le processus corrects dans un environnement de déploiement complexe.

Vérifiez que Request Metrics est activé à l'aide de la console d'administration. Assurez-vous également que le niveau de suivi est défini sur le nombre de sauts inférieur (le suivi des demandes d'écriture s'effectue aux limites du processus). En utilisant la configuration précédemment répertoriée, envoyez une demande http://192.168.0.1/hitcount?selection=EJB&lookup=GBL&trans=CMT à travers leHitCount servlet de la machine 192.168.0.3.

Dans cet exemple, au moins trois enregistrements de trace sont générés :

Un enregistrement de trace pour le plug-in du serveur Web s'affiche dans le fichier journal du plug-in (l'emplacement par défaut est ( racine_plugins/logs/ nom_serveur_web/http_plugin.log ) sur la machine 192.168.0.1.
Un enregistrement de trace pour le servlet s'affiche dans le fichier journal du serveur d'applications (l'emplacement par défaut est racine_profil/logs/appserver/SystemOut.log ) sur la machine 192.168.0.1.
Un enregistrement de trace pour le servlet s'affiche dans le fichier journal du serveur d'applications (l'emplacement par défaut est racine_profil/logs/appserver/SystemOut.log ) sur la machine 192.168.0.1.
Un enregistrement de trace pour l'appel de la méthode du bean d'incrémentation s'affiche dans le fichier journal du serveur d'applications (l'emplacement par défaut est racine_profil/logs/appserver/SystemOut.log ) sur la machine 192.168.0.2.
Un enregistrement de trace pour l'appel de la méthode du bean d'incrémentation s'affiche dans le fichier journal du serveur d'applications (l'emplacement par défaut est racine_profil/logs/appserver/SystemOut.log ) sur la machine 192.168.0.2.

Note: Cette rubrique fait référence à un ou plusieurs fichiers journaux du serveur d'applications. Comme alternative recommandée, vous pouvez configurer le serveur pour utiliser l'infrastructure de journalisation et de trace HPEL (High Performance Extensible Logging) au lieu d'utiliserSystemOut.log ,SystemErr.log ,trace.log , etactivity.log fichiers sur distribués et IBM® i systèmes. Vous pouvez également utiliser HPEL conjointement avec votre z/OS® installations forestières. Si vous utilisez l'infrastructure HPEL, vous pouvez accéder à toutes les informations de journalisation et de trace en utilisant l'outil de ligne de commande LogViewer à partir de votre répertoire bin de profil de serveur. Voir le informations sur l'utilisation de HPEL pour dépanner les applications et obtenir plus d'informations sur l'utilisation de HPEL.

Les deux enregistrements de trace qui s'affichent sur la machine 192.168.0.1 sont semblables à l'exemple suivant :

PLUGIN:
parent:ver=1,ip=192.168.0.1,time=1016556185102,pid=796,reqid=40,event=0
- current:ver=1,ip=192.168.0.1,time=1016556185102,pid=796,reqid=40,event=1 
type=HTTP detail=/hitcount elapsed=90 bytesIn=0 bytesOut=2252

Application server (web container tier)
PMRM0003I: parent:ver=1,ip=192.168.0.1,time=1016556185102,pid=796,reqid=40,event=0
- current:ver=1,ip=192.168.0.1,time=1016556186102,pid=884,reqid=40,event=1 
type=URI detail=/hitcount elapsed=60

L'enregistrement de trace enregistré sur la machine 192.168.0.2 est similaire au suivant :

PMRM0003I: 
parent:ver=1,ip=192.168.0.1,time=1016556186102,pid=884,reqid=40,event=1 
- 
current:ver=1,ip=192.168.0.2,time=1016556190505,pid=9321,reqid=40,event=1              
type=EJB 
detail=com.ibm.defaultapplication.Increment.increment elapsed=40