Improving application performance is an ongoing process. The easiest way to prioritize performance work is by focusing on the slowest piece first. Once we’ve improved performance there, we can look to the next slowest thing, chipping away at each successive bottleneck.
Does it really matter which transaction is the “slowest”?
Maybe not. Every app tends to have a few administrative pages that are usually reserved for internal use. These tend to be reporting type pages that may take quite a long time to process. While these pages might be the slowest, they are not the most impactful to your customers.
Which transaction is the slowest for the majority of users?
Our Web Transaction Analysis feature displays transactions sorted by the most time consuming by default. A transaction’s time consumption is measured by the product of its response time and the number of times it is called within a period of time.
Here we see that this app spends 14% of its time in the
Admin::OrdersController#index transaction. This may not be the most frequently called transaction, nor the slowest transaction. By considering both factors, however, we can see that improving its performance would be the best place to start for this app.
Your web transactions can also be sorted in other ways. We currently offer sorting by “Slowest Average Response Time”, “Apdex most dissatisfying”, “Highest Throughput” and “Standard Deviation”.
For any web transaction, we get an overview and detailed breakdown of how that transaction performs.
We see that his transaction has a reasonable Apdex score of 0.77, with an average response time of 293 ms.
We can also see how this transaction has performed within the current time window (set to the last 30 minutes). While throughput stayed relatively consistent, response time shows nearly a tripling from fastest to slowest. This is reflected in the Apdex score, which dips into the “poor” region briefly.
As we continue down the page, we see a breakdown of performance for this transaction type. We can quickly see how much time is being spent in each component or service used in this transaction. In this case, 61% of our time is being spent processing the Rails controller action itself, while around 30% of the time is spent in the database.
With New Relic, it’s incredibly easy to find performance bottlenecks in your web applications. We’ll guide you right to the slowest parts of your app, so you can improve response time making every customer a happier customer.