IBM Tivoli Composite Application Manager for Application Diagnostics, Version 7.1.0.1
Scenario 5: Determine the cause of high response times
Overview
Annette, the level 2 operator, receives an e-mail to indicate that the WASHighResponseTime situation has triggered for an application.
- Annette navigates to the Tivoli Enterprise Portal and notices in the Application Server Summary workspace, the icon for the application is displaying a critical icon. The flyover for the application indicates that the Average Response time (ms) is high. Annette needs to determine how long the response time has been high.
- Annette double clicks the Application icon, the Application Trend at L1 workspace is displayed. Annette requests historical data by taking the following steps:
- In the Requests - Current Interval View, she clicks the query icon...
Specify time span for query icon
The Select the Time Span window is displayed.
- In the Custom Parameters section, she enters the required values in the Start Time and End Time fields and she clicks OK.
- She sorts by the Average Response Time column.
- Annette uses an external ticketing tool to forward the trend details to Jim, the Middleware/Application Support SME.
- Jim, receives this problem ticket about high response times for a particular application. Jim navigates to the Request Analysis workspace and confirms the problem Annette described.
- To further investigate the problem Jim needs to open MSVE. Jim clicks the Diagnostic Recent Completed Requests link to open the page...
MSVE Server Activity – Recent Requests page
Only requests that contain the URI information from the Request Analysis workspace are displayed. Jim notices that there are a number of client requests with high response times.
- Jim decides to further analyze the transactions by setting trap...
Resident Time – In-Flight
This trap activates the moment an in-flight request takes longer than a specified amount of time (minimum 15 seconds). To set up this trap, Jim must do the following steps:
- Select the trap type.
- Set the trap alerts.
- Activate the trap.
- Jim then sets an action type of Stack Trace and waits for a problem request to trigger the trap.
- After a little while, the problem request triggers the trap.
- This trap also produces a stack trace.
Jim forwards the trouble ticket to Dave, the application developer. Dave works to resolve the problem. This action is outside the scope of ITCAM for Application Diagnostics.
Parent topic:
Scenarios