What is a slow transaction?
A slow transactions is a user request that does not respond in an appropriate amount of time. A transaction is slow if:
- It is more than 20% slower than others of the same type.
- A web request takes longer than one second to complete.
Goal of this tutorial
Learn how to diagnose the root cause of a slow transaction.
Install the easyTravel demo application and follow these steps:
- Run the Production/Standard scenario.
- Switch on the SlowAuthentication Problem Pattern.
- Switch off generic load. Move the slider to the left.
- Open the customer frontend, and log in as a user, such as maria/maria and then as monica/monica.
Import the attached session to perform this tutorial with the recorded session.
- AppMon Client
- Imported attached session
Response time HotSpots
If you are running the scenario on your own, click Open Start Center > Analyze Performance > Pinpoint Transaction Hotspots and click the Open transaction hotspots text link. The Response Time Hotspots dashlet opens.
If you are using the recorded session, follow these steps:
AppMon 2017 May This description applies to AppMon 2017 May. See the 2018 February description in the expandable section below.
In the AppMon Client cockpit, click the Diagnose Performance > Response Time Hotspots node in the recorded session. The Response Time Hotspots dashlet appears.
AppMon 2018 February
- Select the required session in the Session selector.
- In the sidebar, click Dashlets > Response Time Hotspots. The Response Time Hotspots dashlet appears.
With just a click, you can identify which tiers and APIs are slow and contribute to the response time:
- The backend uses approximately 90% of the time.
- The JDBC uses 75% of the API.
- Hibernate uses approximately 20%.
The chart provides even more detail when you set the percentile filter on the top right corner of the dashlet to the slowest 5%.
One click to root cause
The JDBC I/O time is the most significant contributor. For further analysis, click on this area in the chart and the Database dashlet opens. You can see a detailed list of all the executed SQL statements. Notice that 70 calls of verify_location are responsible for approximately 70% of the response time.
Go back to the Response Time Hotspots dashlet and follow these steps:
- Click on the Response Time Hotspots dashlet to drill down from the business backend. The Method Hotspots dashlet opens.
- Select the method
socketRead0(),which consumes a vast amount of time. The detailed caller breakdown appears below. It shows, that 93% originate from
- Drill down to the PurePaths.
- Look at the Contributors tab and the PurePath Hotspots. Notice that you have many single method calls, as opposed to one big time-consuming hotspot, of
socketRead0(). Each last just about 20ms.
- Look at the tree below and note that
socketRead0is called by
- Switch off the Auto Sensors. You can identify the structure of the problem pattern: Many single SQL statements.