What is a Slow Transaction?
Slow transactions are user requests that do not respond in an appropriate amount of time. A transaction is slow if:
- A single transaction is more than 20% slower than others of the same type.
- A web requests takes longer than one second to complete.
Goal of this Walkthrough
The goal of this walkthrough is to 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 (e.g. maria/maria) and then as monica/monica.
- AppMon Client
- Imported attached session
Response Time Hotspots
If you are running the scenario on your own, follow these steps:
- Open the Start Center.
- Go to Analyze Performance.
- Select the Pinpoint Transaction Hotspot. The Response Time Hotspots dashlet opens.
If you are using the recorded session, follow these steps:
- Go to the Cockpit.
- Click the Diagnose Performance node in the recorded session. The Response Time Hotspots dashlet opens.
With just a click, you can identify which tiers and APIs are slow and contribute to the response time:
- The backend uses Approx. 90% of the time.
- The JDBC uses 75% of the API.
- Hibernate uses approximately 20%.
If you set the percentile filter on the top right corner of the dashlet to the slowest 5%, the chart provides even more detail.
Response Time Hotspots
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.