Use this page to learn how to use request metrics by viewing an example.
Example
In this example, the HitCount servlet and the Increment enterprise bean are deployed on two different application server processes. As shown in the following diagram, the Web container tier and EJB container tiers are running in two different application servers. To set up such a configuration, install WebSphere Application Server Network Deployment.
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.
Make sure that request metrics is enabled using the administrative console. Also, make sure that the trace level is set to at least hops (writing request traces at process boundaries). Using 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) CWPRM0003I: 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=60The trace record that is displayed on machine 192.168.0.2 is similar to the following example:
CWPRM0003I: 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
Monitoring application flow
Why use request metrics?
Searchable topic ID: rprf_example