Where can I view service response-time hotspots?

With deep process monitoring enabled, Dynatrace analyzes the response time of each service running within each process. This applies to Java, .NET, Node.js, PHP, Apache webserver, IIS, Nginx, and other technologies.

Each Service page enables you to analyze response time hotspots. Response time hotspots indicate what activities are consuming the most time for each service. To view the hotspot analysis

  1. Select Transactions & services from the navigation menu.

  2. Select the service you want to analyze.

  3. On the service overview page, click either the View requests, View dynamic web requests, or View resources button.

  4. Click the View response time hotspots button to navigate to the Response time analysis page.

On the Response time analysis page you see the average response time observed during the analyzed time frame. On the left side of the infographic, under Distribution, you can see how much time is contributed by calls to other services, calls to databases, and code-level execution. On the right side, under Top findings, we list the biggest hotspots identified by Dynatrace. You can click any of these entries to view further details.

Calls to other services

Click Interaction with services and queues to display details regarding how these calls contribute to the overall response time.

On the left side you see how often the analyzed service calls other services and to what extent these calls contribute to the response time. On the right side, this information is broken down into more detail. In the example above, you see that most of the time is contributed by the Easytravel Customer Frontend service. Click the service name to view the next step in the hierarchy. Once you reach the lowest level (the request level) you see full response-time details for the selected request.

In the example above, we see that EasytravelWebserver:8079 calls the URL /orange.jsf on easytravel Customer Frontend in only 7.46% of the overall requests it initiates—exactly once each time. We see that the response time of /orange.jsf is 255 ms on average. However, because this is called only rarely, it contributes only 19 ms to the average response time of EasytravelWebserver:8079.

If you click the arrow button on the left boundary of the Interaction with services and queues section, you can again move upwards in the hierarchy.

Database requests

Click the Database usage portion of the infographic to access details about the database requests of the analyzed service and to see how they contribute to the response time. The top section offers the same navigation and information offered by the Interaction with services and queues section. Beneath this you can view all database requests.

By clicking the list box in the top right corner, you can sort database statements by average execution time, percentage of calls, invocations, and contribution. By default, the statements that contribute the most to response time are included at the top of the list. Click a SQL statement to view the values for these four attributes.

Code-level visibility

Click Service execution to view how much time the service spent executing its own code.

The lengths of the bars represent the amount of time spent in each particular area. The dark blue color represents CPU time. Click any row name that's rendered as a link to view the related method-level hotspots.

Automatic Hotspots

The Top findings appearing on the right section of the Response time analysis infographic list the hotspots that are the key contributors to the analyzed request.

If a request is slow, you'll see the underlying cause listed under Top findings. Click a finding to view further details. In this example you can see that 226 ms out of 639 ms were spent in a call to PaymentLogic.DoPay!

Response time distribution

Click the circular Response time portion of the infographic to open a chart that shows the response time distribution of all analyzed requests. This shows you if your service has a range of response times or if it performs uniformly.

Typically, web-request services have a wide range of response times. Analyzing a single request often shows a more uniform picture.