For example, I used this performance problem from the New Relic Ruby Kata to make a video tutorial for New Relic University. (The New Relic Ruby Kata is a publicly available practice app with seven intentional performance problems with which to test your APM troubleshooting skills.) You can try this out by deploying your own Ruby Kata app and follow the instructions on the site:
Once I deployed the Ruby Kata app to Heroku and connected to New Relic, I usedSiege to run a load test against my app and generate some data for my app overview dashboard. Siege is an http regression testing and benchmarking utility I downloaded using Homebrew. You can find more info about Siege here.
The Siege test showed my response time was about 4 seconds, which indicated that my application was running slowly and needed some tuning.
The video tutorial below shows how I used New Relic’s application overview dashboard to investigate the performance problem and isolate the trouble-makers.
My investigation revealed that the database call was the biggest problem, taking about 4 seconds.
From there, I used the transactions option under the monitoring tab to dig deeper into the performance problem and see more details about what was happening in my app. Because I only tested one page of my app, I had one transaction in the list — the loop controller. Clicking on that opened a window with more details about the transaction.
This view revealed that there were two database calls causing me the most problems. The Icon#find call represented in red and the loop/index in purple. In this Transaction summary view, it’s pretty obvious that the Icon#find call was a problem–consuming almost 70% of the time.
Clicking on Trace details allowed me to dig even deeper into this problem area. Right away, you’ll notice a red bar showing that almost all of the app’s time was spent making 1,000 database calls.
Once I figured out that the problem was in the LoopController#index, and that there was a template I needed to look at as well, I was able to tweak the code and speed up performance using a Rails includes method. That effectively cut my database calls from 1,001 to just 2.
Finally, I deployed my fix and ran the same test with Siege to see how the app performed.
The app Overview dashboard show that the changes cut my application response time down to less than half a second, making my app almost eight times faster.
Investigating performance problems is not only easy with New Relic APM, it’s really fun too! Try it yourself with the New Relic Ruby Kata and have some fun improving your application’s performance.