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

Die von Request Metrics überwachten Informationen können für späteres Abrufen und Analysieren in Protokolldateien gespeichert und/oder an ARM-Agenten (Application Response Measurement) gesendet werden.
Während der Verarbeitung der Transaktion im System überwacht Request Metrics weitere Informationen, damit die Protokollsätze jeder Komponente korreliert werden können und somit ein vollständiges Bild dieser Transaktion liefern. Das folgende Beispiel veranschaulicht, wie das Ergebnis aussehen könnte:
HTTP-Anforderung/Trade/Szenario             ------------------------------> 172 ms
     Servlet/Trade/Szenario -----------------------------> 130 ms
         EJB TradeEJB.getAccountData --------------------->  38 ms
              JDBC select -------------------------------->   7 ms 

Transaktionsablauf

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.

Es werden fünf Filtertypen unterstützt:
  • 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.

Anmerkung: Filter können nur angewendet werden, wenn die Anforderung WebSphere Application Server erreicht.

Vorgehensweise

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.

Beispiel

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.

In diesem Beispiel werden mindestens drei Tracesätze generiert:
  • 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.
  • [AIX Solaris HP-UX Linux Windows][z/OS]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.
  • [IBM i]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.
  • [AIX Solaris HP-UX Linux Windows][z/OS]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.
  • [IBM i]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.
Anmerkung: Dieser Artikel referenziert eine oder mehrere Protokolldateien des Anwendungsservers. Alternativ dazu wird empfohlen, den Server so zu konfigurieren, dass er die HPEL-Protokoll- und -Traceinfrastruktur (High Performance Extensible Logging) verwendet und nicht die Dateien SystemOut.log , SystemErr.log, trace.log und activity.log auf verteilten oder IBM® i-Systemen. Sie können HPEL auch in Verbindung mit Ihren nativen z/OS-Protokolleinrichtungen verwenden. Wenn Sie HPEL verwenden, können Sie mit dem Befehlszeilentool LogViewer im Verzeichnis "bin" des Serverprofils auf alle Ihre Protokoll- und Tracedaten zugreifen. Weitere Informationen zur Verwendung von HPEL finden Sie in der Dokumentation zum Einsatz von HPEL für die Fehlerbehebung in Anwendungen.
Die beiden Tracesätze, die auf der Maschine 192.168.0.1 angezeigt werden, gleichen dem folgenden Beispiel:
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 
Der Tracesatz, der auf der Maschine 192.168.0.2 angezeigt wird, gleicht dem folgenden Beispiel:
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

Symbol, das den Typ des Artikels anzeigt. Taskartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tprf_requestmetrics
Dateiname:tprf_requestmetrics.html