Three ways to increase New Relic RPM’s usefulness
Here at Katipo, we’re using New Relic RPM to monitor our deployed Kete applications, to help make things as fast as possible. In order to make New Relic as useful as possible, I’ve been trying out three New Relic RPM features, some available in only the latest versions of RPM, on one of those sites. These recent and little-known features aren’t enabled by default, so I’m going to run you through them and how to set them up in this post.
If you don’t yet use New Relic RPM, you can get a Lite account for free by going to newrelic.com, where you can also test drive New Relic RPM on a real application.
Custom request parameters
New Relic does it’s best to record as much information about the current request as possible. The URL, split down into controller, action, id etc, the request referrer, GET and POST data…. but there is data that it doesn’t know about. Things like the current locale, the user who is currently logged in, or custom session params. Thankfully, there is a solution.
New Relic RPM contains a method for adding custom data to each transaction or error that is sent to it’s servers. Utilize this method inside of a before_filter in your application controller, and you’ll be gathering that extra data in no time. Here is the code we use.
# Collect additional debug details for New Relic RPM is available
# Do this after all other before filters so details are present
before_filter :set_new_relic_custom_parameters
def set_new_relic_custom_parameters
return unless defined?(NewRelic)
NewRelic::Agent.add_custom_parameters(
:locale => (I18n.locale if I18n.locale),
:account => (logged_in? ? current_user.login : 'guest'),
:return_to => (session[:return_to] if session[:return_to])
)
end
private :set_new_relic_custom_parameters
Now, whenever RPM sends information about slow web requests or error reports, you’ll have more data to help replicate the issue.
Passenger Queue Wait
Sometimes the slowness might not be your app, but your app server. How do you tell if it’s serving requests fast enough? New Relic RPM now has the ability to report how long your visits were waiting in the ‘queue’, that is, the time between requesting the site and Apache actually processing that request. Getting this working is fairly simple.
RequestHeader set X-REQUEST_START “%t”
Simply set that in either your main apache.conf file, the VirtualHost directive, or a Directory directive.
Also, ensure that the headers Apache module is enabled. On Debian, you can do this by running the following as root.
# a2enmod headers
That’s all it takes. Now, when RPM sends along information, it’ll send how long each request stayed in the queue, and display it at New Relic RPM’s web interface, on all graphs as ‘Queue Wait’. This should give you an indication of whether your application server is performing well.
Important Note: If you run your application across multiple machines, each machine needs this header, and the clock on each machine must be synced with NTP or similar, or you’ll end up with very incorrect queue times. Users who run the entire site off one box need not worry about this issue.
Garbage Collection delays
I’m not going to go into much detail about Ruby Garbage collection here. Google ‘Ruby Garbage Collection’ if you want to know more. Put simply though, in Ruby, while Garbage Collection runs, it stops the processing of your app. This could lead to slow page requests if it garbage collector, or GC, runs multiple times in the same request.
There are ways to tweak this using settings, but how do you know if it’s a problem to begin with? If you use Ruby Enterprise Edition, or another version of Ruby with the Railsbench GC patches compiled in, then all you need is the following line in your application.
GC.enable_stats if defined?(GC) && GC.respond_to?(:enable_stats)
For Ruby on Rails users, you can stick that at the bottom of your config/environment.rb file. Basically, if GC is defined, and responds to the correct method, then use it. RPM will send this information back to New Relic, where you can view how long GC took in each of your requests, and deal with it accordingly.
Conclusion
Well, that’s all for now. Please feel free to share any additional features which help make New Relic even more useful in the comments.