Utilité de Request Metrics

Request Metrics est un outil de suivi des transactions individuelles qui enregistre le temps de traitement de chaque composant WebSphere Application Server majeur.

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 

Flux de transactions

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 (Enterprise JavaBeans) 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, comprend également 38 millisecondes au niveau de l'EJB et de JDBC (Java™ Database Connectivity). 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 mesures de demandes peuvent alors suivre le temps de réponse de ces transactions dans l'environnement WebSphere Application Server. 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.

Pourquoi et quand exécuter 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.

Remarque : Les filtres ne sont applicables que pour la première requête acceptée par WebSphere Application Server.

Procédure

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 indiqué dans le diagramme suivant, le niveau du conteneur Web et les niveaux du conteneur EJB (Enterprise JavaBeans) s'exécutent dans deux serveurs d'applications différents. Pour définir une configuration de ce type, installez WebSphere Application Server, Network Deployment.

Exemple

Supposons que le serveur Web et le niveau du conteneur Web s'exécutent tous deux sur la machine 192.168.0.1, et que le niveau du conteneur EJB (Enterprise JavaBeans) 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). A l'aide de la configuration répertoriée précédemment, envoyez une demande http://192.168.0.1/hitcount?selection=EJB&lookup=GBL&trans=CMT via le servlet HitCount à partir 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_plug_ins/logs/nom_serveur_Web/http_plugin.log ) sur la machine 192.168.0.1.
  • [AIX Solaris HP-UX Linux Windows][z/OS]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.
  • [IBM i]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.
  • [AIX Solaris HP-UX Linux Windows][z/OS]Un enregistrement de trace pour l'appel de méthode de bean d'incrément 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.
  • [IBM i]Un enregistrement de trace pour l'appel de méthode de bean d'incrément 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.
Remarque : Cette rubrique fait référence à un ou plusieurs des fichiers journaux de serveur d'applications. Il est recommandé de configurer le serveur de telle sorte qu'il utilise l'infrastructure de journalisation et de trace HPEL (High Performance Extensible Logging) à la place des fichiers SystemOut.log, SystemErr.log, trace.log et activity.log sur les systèmes distribués et IBM® i. Vous pouvez également utiliser HPEL conjointement avec vos fonctions de journalisation z/OS natives. 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. Pour plus d'informations sur l'utilisation de HPEL, voir les informations sur l'utilisation de HPEL en vue du traitement des incidents liés aux applications.
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

Serveur d'applications (niveau du conteneur Web)
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

Icône indiquant le type de rubrique Rubrique de tâche



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tprf_requestmetrics
Nom du fichier : tprf_requestmetrics.html