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 so that you can see what activities are consuming the most time for each service. Click the View response time hotspots button to view hotspot analysis.
Response time hotspots
Click any area in the infographic to view further details.
On the Response time analysis page you see the average response time observed during the analyzed time frame. The infographic also shows 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.
The Response time contribution area shows you how much time calls to other services or databases have contributed to the overall response time of the selected service. Click any of these entries to view further details. Self time represents time that the service spent executing its own code. This is where you’ll find method-level data.
Calls to other services
Click Interaction with services and queues to display detail regarding how these calls contribute to the overall response time.
This is a hierarchical control. On the left side you see how often the analyzed service calls other services and how much these calls contribute to the response time. On the right side this 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 up in the service hierarchy. Once you reach the lowest level (the request level) you see full response-time details for the selected request.
In this case we see that
EasytravelWebserver:8079 calls the URL
easytravel Customer Frontend in only 7.46% of instances—exactly once each time. We see that the response time of
/orange.jsf is 255 ms on average, but because it’s called rarely it only contributes 19 ms to the average response time of
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.
You can sort database statements based on contribution, average execution time, number of invocations, and more. 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 further detail, like number of rows and fetches.
Click Self time 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. In the example above you can see that the service spends most of its execution time in PHP compilation and that most of this time is CPU time.
Click any row name that’s rendered as a link to view the related method-level hotspots. This section is dynamic and displays the metrics that are most relevant to the service. In this example, we’ve analyzed an Apache web server that also hosts PHP. Clicking the PHP compilation link above provides the following analysis:
This section varies based on the technology you are monitoring (.NET, Java, Apache, PHP, Node.js, or other). Below is an example .NET method-level hotspot view:
Here’s an example Java method-level hotspot view:
The right-hand section of the **Response time **infographic lists the **Top findings **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
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 performs uniformly.
Typically, web-request services have a wide range of response times. Analyzing a single request often shows a more uniform picture.
The vertical dashed line on the right end the chart represents the 90th percentile. Outliers beyond this point are not included because they would otherwise skew results.
We use this same approach for service response-time charts. Turn on the Show slowest 10% in chart setting to view outliers above the 90th percentile.
In the example above, the distance between the light blue Response time line and the dark blue Response time of the slowest 10% line shows that the median Response time (13 ms) is far better than the Response time of the slowest 10% (419 ms).
The Hotspots for slowest 10% button appears when you add the slowest 10% of response times to the response time chart. Use this approach to analyze the response times of outliers or your slowest requests.
You may be surprised by the results you see here as this analysis doesn’t include “normal” requests; it only includes those results that are part of the slowest 10%.