Einsatzmöglichkeiten für Request Metrics
Request Metrics ist ein Tool, mit dem Sie einzelne Transaktionen verfolgen können. Es zeichnet die Verarbeitungszeit in allen wichtigen WebSphere Application Server-Komponenten auf.
Vorbereitende Schritte
HTTP-Anforderung/Trade/Szenario ------------------------------> 172 ms
Servlet/Trade/Szenario -----------------------------> 130 ms
EJB TradeEJB.getAccountData ---------------------> 38 ms
JDBC select --------------------------------> 7 ms

Dieser Transaktionsablauf mit den zugehörigen Antwortzeiten kann Benutzern helfen, die für den Durchsatz problematischen Bereiche und Probleme zu ermitteln, die auf Ressourcenbeschränkungen zurückzuführen sind. Beispielsweise können Sie anhand des Ablaufs feststellen, ob eine Transaktion die meiste Zeit im Web-Server-Plug-in, im Web-Container, im EJB-Container oder in der Back-End-Datenbank verbringt. Die für jede Ebene erfasste Antwortzeit beinhaltet die auf dieser Ebene und die in unteren Ebenen verbrachte Zeit. Beispiel: Die Antwortzeit für das Servlet, 130 Millisekunden, enthält auch die für Enterprise-Beans und Java Database Connectivity aufgebrachten 38 Millisekunden. Deshalb können dem Servletprozess 92 Millisekunden angerechnet werden.
Request Metrics überwacht die Antwortzeit für eine bestimmte Transaktion. Da Request Metrics einzelne Transaktionen überwacht, wirkt sich die Verwendung von Request Metrics auf die Leistung des Systems aus. Die Auswirkungen auf die Systemleistung können durch die Verwendung von Anforderungsfiltern jedoch gemildert werden.
Tools können beispielsweise synthetische Transaktionen einbringen. Daraufhin kann Request Metrics die Antwortzeit in der Umgebung von WebSphere Application Server für diese Transaktionen überwachen. Eine synthetische Transaktion ist eine Transaktion, die von Administratoren in das System eingebracht werden, um den Durchsatz auf dem System aktiv zu testen. Diese Informationen können Administratoren bei der Leistungsoptimierung der Website und gegebenenfalls beim Ergreifen der richtigen Maßnahmen zur Fehlerbehebung helfen. So können die von Request Metrics bereitgestellten Informationen als Alert-Mechanismus verwendet werden, um festzustellen, wann der Durchsatz für einen bestimmten Anforderungstyp die zulässigen Grenzwerte überschreitet. Mit dem Filtermechanismus von Request Metrics kann der Fokus auf bestimmte synthetische Transaktionen gesetzt und damit der Durchsatz in diesem Szenario möglicherweise verbessert werden.
Informationen zu diesem Vorgang
Wenn Sie die Problembereiche isoliert haben, können Sie sich mit den Filtermechanismen von Request Metrics speziell auf diese Bereiche konzentrieren. Beispiel: Sie haben ein Problem auf ein bestimmtes Servlet oder eine bestimmte EJB-Methode eingegrenzt. Verwenden Sie jetzt die URI-Algorithmen oder den EJB-Filter, um die Instrumentierung nur für dieses Servlet bzw. diese EJB-Methode zu aktivieren. Der Filtermechanismus unterstützt eine zielgerichtete Leistungsanalyse.
- Quellen-IP-Filter
- URI-Filter
- Namensfilter für EJB-Methode
- Filter für JMS-Parameter
- Filter für Web-Service-Parameter
Wenn die Filterfunktion aktiviert ist, werden nur für Anforderungen, die mit dem Filter übereinstimmen, Request-Metrics-Daten generiert, Protokolldatensätze erzeugt und ARM-Schnittstellen aufgerufen. Auf diese Weise können Sie Aufgaben in einem laufenden System ausführen, insbesondere zur Generierung von Traceinformationen, um den Durchsatz besonderer Anforderungsarten bei normaler Auslastung zu ermitteln und Anforderungen von anderen Quellen, die sich auf das System auswirken können, zu ignorieren.
Vorgehensweise
- Weitere Informationen zu Request Metrics finden Sie in den detaillierten Erläuterungen in diesem Abschnitt.
- Request Metrics konfigurieren und aktivieren.
- Leistungsdaten abrufen und Anwendungsfluss überwachen.
- Überwachung auf Anwendungen erweitern, die unter Umständen zusätzliche Instrumentierungspunkte erfordern.
Beispiel
Auf dieser Seite wird beschrieben, wie Sie Request Metrics anhand eines Beispiels verwenden können.
In diesem Beispiel werden das Servlet HitCount und die Enterprise-Bean Increment in zwei unterschiedlichen Anwendungsserverprozessen implementiert. Wie die folgende Abbildung zeigt, werden die Web-Containerschicht und die EJB-Containerschichten in zwei unterschiedlichen Anwendungsservern ausgeführt. Für eine solche Konfiguration müssen Sie WebSphere Application Server Network Deployment installieren.

Angenommen, Web-Server und Web-Container werden auf der Maschine mit der IP-Adresse 192.168.0.1 und der EJB-Container auf einer zweiten Maschine mit der IP-Adresse 192.168.0.2 ausgeführt. Die Clientanforderungen können von einer anderen Maschine, z. B. einer Maschine mit der IP-Adresse 192.168.0.3, gesendet werden.
Zur Veranschaulichung der Verwendung von Quellen-IP-Filtern wurde ein Quellen-IP-Filter (192.168.0.3) definiert und aktiviert. Diese Aktion ermöglicht das Tracing für Anforderungen, die von der Maschine 192.168.0.3 über http://192.168.0.1/hitcount?selection=EJB&lookup=GBL&trans=CMT gesendet werden. Für die Anforderungen, die von einer anderen Maschine abgesetzt werden, wird kein Tracing durchgeführt, da die Quellen-IP-Adresse nicht in der Filterliste aufgeführt ist.
Wenn Sie einen Quellen-IP-Filter erstellen, wird für jede Anforderung, die über diese Quellen-IP-Adresse abgesetzt wird, ein effektives Tracing durchgeführt. Mit diesem Tool können Leistungsprobleme auf Systemen unter Last lokalisiert werden. Wenn die normale Last auf andere IP-Adressen zurückzuführen ist, wird für deren IP-Adressen kein Tracing durchgeführt. Wenn Sie die definierten Quellen-IP-Adressen verwenden, um Anforderungen zu generieren, können Sie an den verschiedenen Hops Leistungsengpässe erkennen, wenn Sie die Tracesätze des Systems unter Last mit den Tracesätzen einer Ausführung ohne Last vergleichen. Dadurch können Sie Optimierungsvorgänge leichter auf den richtigen Knoten fokussieren und Prozesse in einer komplexen Implementierungsumgebung ausführen.
Vergewissern Sie sich über die Administrationskonsole, dass Request Metrics aktiviert ist. Stellen Sie auch sicher, dass die Tracestufe mindestens auf Hops (Anforderungstraces an Prozess-Grenzwerten schreiben) eingestellt ist. Wenn Sie die oben aufgeführte Konfiguration verwenden, senden Sie von der Maschine mit der IP-Adresse 192.168.0.3 über das Servlet HitCount eine Anforderung http://192.168.0.1/hitcount?selection=EJB&lookup=GBL&trans=CMT.
- Es wird ein Tracesatz für das Web-Server-Plug-in in der Plug-in-Protokolldatei (Standardposition ist Stammverzeichnis_für_Plug-ins/logs/Name_des_Web-Servers/http_plugin.log ) auf der Maschine 192.168.0.1 angezeigt.
Es wird ein Tracesatz für das Servlet in der Protokolldatei des Anwendungsservers (Standardposition ist Profilstammverzeichnis/logs/appserver/SystemOut.log) auf der Maschine 192.168.0.1 angezeigt.
Es wird ein Tracesatz für das Servlet in der Protokolldatei des Anwendungsservers (Standardposition ist Profilstammverzeichnis/logs/appserver/SystemOut.log) auf der Maschine 192.168.0.1 angezeigt.
Es wird ein Tracesatz für den Aufruf der Inkrement-Bean-Methode in der Protokolldatei des Anwendungsservers (Standardposition ist Profilstammverzeichnis/logs/appserver/SystemOut.log) auf der Maschine 192.168.0.2 angezeigt.
Es wird ein Tracesatz für den Aufruf der Inkrement-Bean-Methode in der Protokolldatei des Anwendungsservers (Standardposition ist Profilstammverzeichnis/logs/appserver/SystemOut.log) auf der Maschine 192.168.0.2 angezeigt.
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
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