Dynatrace AppMon 6.5 Documentation

Other Doc Versions & KB

Skip to end of metadata
Go to start of metadata

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:

  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 (e.g. maria/maria) and then as monica/monica.


Detailed Steps

Response Time Hotspots

If you are running the scenario on your own, follow these steps:

  1. Open the Start Center.
  2. Go to Analyze Performance.
  3. Select the Pinpoint Transaction Hotspot. The Response Time Hotspots dashlet opens.

If you are using the recorded session, follow these steps:

  1. Go to the Cockpit.
  2. 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.

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.