IBM Tivoli Composite Application Manager for Application Diagnostics, Version 18.104.22.168
Scenario 5: Determine the cause of high response times
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.