September 17, 2008

Posted by John

Tagged monitoring, performance, plugins, and review

Older: Parsing XML with Ruby

Newer: Some Design Attention

Rails App Performance Monitoring

About a week ago, I signed up for a free trial of New Relic’s RPM. The only app that I really manage day to day right now is My Mile Marker (M3 as I’ll now refer to it), so I installed the plugin and redeployed the app.

Overview Page

I was stoked a day later when I logged into the New Relic overview for M3 and started checking out what they had to offer. The graphs are nice and give you a good idea of what is going on in your application. I could see that M3 uses between 125MB – 150MB of RAM (60-75MB per mongrel instance) and that CPU utilization is pretty low. Also, the response time is generally related to the load and is perfectly acceptable.


Controller and Action Performance Page

On the controllers page, they have a cool chart that shows your slowest controller actions. Obviously, actions that write to the database are slower than those that read.


If you click on an action, you are presented with a breakdown of that action, so you can see what is causing the slowness. Very helpful. For example, in the /histories/destroy action, History#save is taking up most of the time. That is most likely because we have to adjust the numbers of previous histories each time you delete a history.


Index Hunter

One of my favorite graphs/features in New Relic is the index hunter. It’s a really practical application of performance monitoring. If queries are really slow, chances are they need some sort of database index.


Scalability Charts

One of the more interesting features that will probably be of interest to those managing large applications is the scalability analysis. New Relic presents a scatter plot chart with a line through it that is your “scalability” line. Basically, if this lines starts going up on the CPU, response time, or database scalability graph, it is time to start beefing up your servers or adding some caching. Below is the database scalability analysis for M3. We have a ways to go before needing to address things.



After using the service for a bit I thought of a few things that would be nice. First, more information on what the charts really mean. Charts are a great way to visualize information but if you don’t know what the numbers “mean” it doesn’t matter. There were a few places I wasn’t sure on what things were until I visited the help section. More help inline with the charts would be nice.

Second, I’d like to be able to create custom events. New Relic is measuring performance. Performance is all about tweaking and measuring. When I tweak something, such as add a database index, I’d like to see how that affects performance. It would be cool to show the events you create over-layed on each of the line charts. This would all you to see that your response time lowered and immediately know that it was because you added a database index or some caching. I can see this being really helpful for teams that aren’t always aware of everything other team members are doing.


There is no reason not to add New Relic light into all your applications. It is free, keeps track of 30 minutes of data and will help you when stuff goes wrong. If you want things like the index hunter and the scalability analysis, you are going to need to pay, but if you have an app that big, you are probably making money on it so it the price won’t matter. Trust me, after having to figure out some of the things manually that New Relic automates, it is worth the money.

Related Links


  1. Hi!

    I already submitted a feature request entitled API to add bars for interesting events on graphs

    Go and vote for it :)

  2. Have you looked at the request-log-analyzer gem? Does pretty much the same, but from you rails log file. Only it is less fancy (textbased).

  3. @Francois – Great minds think alike. :)

    @Bart – Cool. Haven’t seen that. It gives the same kind of overview, but where new relic earns its keep is in the premium features. Some of the things I didn’t talk about are the transaction tracing and error tracking.

Sorry, comments are closed for this article to ease the burden of pruning spam.


Authored by John Nunemaker (Noo-neh-maker), a programmer who has fallen deeply in love with Ruby. Learn More.


Release your software more often with fewer problems.
Flip your features.