Example: Using request metrics

 

+

Search Tips   |   Advanced Search

 

Example

In this example, the HitCount servlet and the Increment enterprise bean are deployed on two different appserver processes. As shown in the following diagram, the Web container tier and EJB container tiers are running in two different appservers. To set up such a configuration, install WAS ND.


Assume that the Web server and the Web container tier both run on machine 192.168.0.1, and the EJB container tier runs on a second machine 192.168.0.2. The client requests might be sent from a different machine; 192.168.0.3, for example, or other machines.

To illustrate the use of source IP filtering, one source IP filter (192.168.0.3) is defined and enabled. You can trace requests that originate from machine 192.168.0.3 through...

http://192.168.0.1/hitcount?selection=EJB&lookup=GBL&trans=CMT

However, requests that originate from any other machines are not traced because the source IP address is not in the filter list.

By only creating a source IP filter, any requests from that source IP address are effectively traced. This tool is effective for locating performance problems with systems under load. If the normal load originates from other IP addresses, then its requests are not traced. By using the defined source IP address to generate requests, you can see performance bottlenecks at the various hops by comparing the trace records of the loaded system to trace records from a non-loaded run. This ability helps focus tuning efforts to the correct node and process within a complex deployment environment.

Verify request metrics is enabled using the console. Also, make sure that the trace level is set to at least hops (writing request traces at process boundaries).

Use the configuration previously listed, send a request...

http://192.168.0.1/hitcount?selection=EJB&lookup=GBL&trans=CMT

...through the HitCount servlet from machine 192.168.0.3.

In this example, at least three trace records are generated:

The two trace records that are displayed on machine 192.168.0.1 are similar to the following example:

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 


The trace record that is displayed on machine 192.168.0.2 is similar to the following example:

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



 

Related tasks

Monitor application flow
Why use request metrics?