When choosing between multiple software applications, users will always go with the fastest one (assuming they’re all equally reliable).

As a software developer, once you have ensured your application’s overall quality, robustness, and reliability, its acceptance and reputation among users depend primarily on how fast and responsive it is. Therefore, it is vital to equip your analysis toolkits with measures that speak of an application’s speed.

Response time is an effective metric for evaluating the speed of individual web transactions and, therefore, the whole application. As a result, there is a lot of value in analyzing the distribution of response times of your application’s endpoints to understand performance.

This post will dive into response time metrics for web applications and common causes of low response times. We’ll also discuss APM tools and how they enable organizations to effectively analyze response time distributions and correlate them with other metrics to gain insights about boosting performance.

Here’s an outline of what we’ll be covering so you can easily navigate or skip ahead in the guide –

Understanding Response Time

As the name suggests, response time is the amount of time it takes for the server to respond to a client’s request. A lower response time means that the server is very quick in responding to the user’s request. Conversely, an endpoint with a higher response time would keep the client waiting to hear back.

There are two common metrics to analyze response times: mean response time and 95th percentile response time.

Mean response time: This is the average response time for each request (mean overall requests). The lesser this value is, the better.

95th percentile response time: This metric represents the amount of time it took for 95% of the transactions to get completed. Because we want all endpoints to respond in the least possible time, the closer this value is to the mean response time, the better.

Peak response time: Another useful metric here is the longest amount of response time taken among all the requests. This can be beneficial for identifying the peak values slowing the system down.

To learn more about response time monitoring, check out the Monitoring Application Response Times post on our blog.

Common Causes of High Response Times

There are n-number of reasons for an application to be sluggish in responding. Here is a list of some of the possibilities:

  • Bulky, slow dependencies
  • High website traffic (too many requests)
  • Slow database queries
  • Slow external APIs 
  • Bad logic/memory bloat/memory leak 
  • Insufficient compute resources (causing even optimal code to not perform adequately)
  • Network bandwidth limitations

It is important to be aware and keep track of the factors responsible for your application’s limited performance. This is the first and foremost step toward lowering response times and boosting overall performance.

How to Properly Analyse Response Time using APM

However, even though it was easy to list down the superset of possible reasons for higher response times, identifying the exact root cause in your case isn’t as straightforward. 

The possibilities in the above list span a vast landscape of an application’s infrastructure (software dependencies, hardware compute resources, databases, external APIs, etc.). Therefore, as you can imagine, manually monitoring all these different aspects of an application 24 x 7 isn’t realistically feasible. Ideally, you need an automated system that can monitor and track all aspects of your application’s performance and condense the statistics into concrete metrics and actionable insights that inform your strategy to boost performance.

This is where Application Performance Monitoring (APM) tools like Scout come into the picture. Below is a screenshot from Scout’s dashboard showing the performance distribution and other metrics for our product’s main website.

Response time distribution in Scout’s dashboard

As you can see, a lot is going on here in the overview. We can see the mean and 95th response time distribution for 60 minutes, along with information about the relative times for each request type (Redis, Controller, InfluxDB, etc.). Additionally, below the bar graphs, you can see the most valuable metrics presented in big numbers, and their distributions visualized right below them.

Moreover, every aspect of this visualization you see here is dynamic. You can filter the data points by request types and metrics, zoom in on a smaller timeframe to get more information, and more.

undefined

Zooming in on a timeframe

This way, you can simply click and drag over the timeframe in question to identify and analyze anomalies causing issues. 

There’s also the ‘Web Endpoints’ dashboard for getting information about all your endpoints listed in one view (sorted by time consumed).

Web Endpoints View in Scout

Here, you can also dive deeper into a specific endpoint and learn more by clicking on it.

This way, you can visualize the response time distribution across all requests for a specific endpoint and easily identify slower outliers against your average.

Correlate other Metrics with Response Time Analysis

In the dashboards we saw, apart from the response time metrics, you can also see others like memory allocation, error rates, throughput, customer satisfaction (ApDex) scores, time consumed, and more.

Selecting metrics to correlate

Another helpful feature Scout offers is the ability to correlate these metrics with each other. All you need to do is select any two metrics you want to observe correlations for. For instance, you could correlate a relatively higher error rate during a specific timeframe with increased response times by selecting the two as shown below:

undefined

Mean response time (bar graph) and error rate (yellow line) correlated

These correlations can be vital in identifying the reason behind abnormal response rates and recognizing causality if any.

Conclusion

As web apps continue to become faster and faster, no user likes to wait for lengthy ‘loading’ progress bars in applications. An effective analysis of server response times enables developers to identify time-taking operations and optimize them to improve overall application speed.

This post talked about understanding application response times and some common causes of slower responses. We also discussed the analysis of response times and the overall efficacy of APM tools in simplifying performance evaluation.

Now that you have a decent understanding of the significance of response time metrics and APM tools for analysis, go ahead and invest in an APM tool for you and your organization. Receive real-time alerts and insights about bottlenecks in performance so you can make fixes before the user catches wind of anything. 

Get started with Scout using a 14-day free trial (no credit card needed!) or schedule a demo with our experts today.