Analyzing a slow transaction

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:

  1. Run the Production/Standard scenario.
  2. Switch on the SlowAuthentication Problem Pattern.
  3. Switch off generic load. Move the slider to the left.
  4. 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.


Detailed steps

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:

  1. Select the required session in the Session selector.
  2. 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%.

Response Time Hotspots
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.

Database dashlet
Database dashlet

Go back to the Response Time Hotspots dashlet and follow these steps:

  1. Click on the Response Time Hotspots dashlet to drill down from the business backend. The Method Hotspots dashlet opens.
  2. Select the method socketRead0(), which consumes a vast amount of time. The detailed caller breakdown appears below. It shows, that 93% originate from PreparedStatement.ExecuteUpdateX().
  3. Drill down to the PurePaths.
  4. 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.
  5. Look at the tree below and note that socketRead0 is called by executeQuery of PreparedStatement.
  6. Switch off the Auto Sensors. You can identify the structure of the problem pattern: Many single SQL statements.