We’ve done a major revamp of our response time analysis view to make them more efficient and visually appealing.
To access response time analysis:
- Click the Services tile on your Ruxit homepage.
- Select a service to analyze.
- Click the View response time hotspots button at the bottom of the page.
You can also access the new response time analysis from any Web request details page:
The response time analysis page provides performance and hotspot information related to the selected service. From here you can easily navigate to further details.
The first section of the infographic shows average response time for the selected time frame. Clicking this section displays a chart that explains the distribution of response times across all requests observed during the time frame.
The next section breaks the response time down into time spent making requests to other services (Interaction with services and queues), time spent in the database (Database usage), and time spent executing the request’s code (Self time). Clicking these metrics gives you access to further details.
Ruxit provides answers, not just data. This is why the Top findings section shows you the hotspots that are the key contributors to the response time of the analyzed request. In other words, if a request is slow, you’ll see you the reasons in this list. Click this list to view further details on the top findings. In this included example you can see that 226 of 639 ms were spent calling PaymentLogic.DoPay!
Analyzing requests to other services
Click Interaction with services and queues to view the requests that your service makes to other services. In the left section you’ll find a summary. On the right you see a more detailed breakdown and navigation to further details. In the screenshot below you can see that 44% of all dotNetBackend_easyTravel_x64:9100 requests make calls to other services. And when a request makes a call, it makes exactly one call. These calls contribute 257 ms on average to the overall response time of 639 ms (so roughly a third). On the right-hand side you can see that the service calls two other services: Payment Logic and a web server (EasyTravelBackendWebserver). The infographic makes it clear that Payment Logic contributes the majority to the response time and that the calls to the web server are of less concern.
By selecting the Payment Logic service you can view more details about the calls to Payment Logic. As it turns out, there’s only a single web service method associated with this service: DoPay.
By selecting the PaymentLogic.DoPay web service method you can see that each request to PaymentLogic.DoPay lasts 822 ms. However because the service only calls DoPay in 27% of cases, on average it only contributes 226 ms. We’ve found the primary response time contributor to this service!
Analyzing how database requests contribute to response time
By clicking Database usage in the infographic you can view details about the database requests of the analyzed service and how those requests contribute to the response time. The first horizontal tile offers the same navigation and information offered for service calls. Beneath this section you’ll find a new section that lists all the database statements. You can sort this list in different ways (contribution, average execution time, number of invocations, and more). By default Ruxit displays those database requests that contribute the most to response time at the top of the list.
Click a SQL statement to view even more details, like number of rows or number of fetches.
Code-level performance analysis
Last but not least, by clicking Self time you can view the time spent executing the code of the service itself (Self time). Click any row to view the method-level hotspots. This section is dynamic and shows whatever is relevant to the service based on technology type (.NET, Java, Apache, PHP or Node.js).
If you experience performance degradation, the new view will show you the root cause. The Top Findings section tells you what went wrong.
In this example, the service spent more time executing database queries.
One click and you’ll see the culprit: a single query takes much more time to execute on the database.
Here’s another example where the service in question executes the same statement more often than it did previously. You can see very clearly that the service spends more time in the database, and that it makes more database calls (see Invocations per Call). Ruxit even shows you exactly which statement is executing more frequently:
Understanding change in response time distribution
In analyzing response time degradation, it’s helpful to know if every transaction has become slower or if only certain transactions are now slower. Click the red Response time circle in the infographic to view the response time distribution and its change. What you see here is that prior to the degradation no request took longer than 114 ms. During the Problem timeframe only 60% of calls were fast, while 40% took more than a second each. The service didn’t degrade uniformly; it experienced a major shift in its response time spread.