$ cd test # from your rails app root
$ ruby unit/a_model_test.rb

As compared to:

$ ruby -I"lib:test" "/usr/local/Cellar/ruby-enterprise-edition/1.8.7-20090928/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake/rake_test_loader.rb" "test/unit/a_model_test.rb"

Definitely a hand to forehead moment when I read that! Found it in a comment here:

https://rails.lighthouseapp.com/projects/16213/tickets/8

*Assumes your ruby command is set up correctly in your shell’s environment, of course.

If you prefer to store your MongoDB data all under your home directory, you might find Mislav’s gist suits your needs instead:

http://gist.github.com/265272

If you prefer installing from source, check out this post:

http://shiftcommathree.com/articles/how-to-install-mongodb-on-os-x

Enjoy.

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.

But Github was building gems for some time, and due to it’s continuing popularity, many well known Ruby on Rails developers and companies switched permanently to Github for their gem building/hosting at the time, so it’s likely that quite a few gems you’ve got installed are from Github.

To help transition over from Github to Gemcutter, Maxim Chernyak wrote a great utility called off_github, which looks at your list of gems, and tells you which ones you’re installed from Github, and whether they can be reinstalled from Gemcutter. It saves a lot of time and effort  than having to do it manually. So here’s how to get started….

Firstly, lets get the latest version of Rubygems. This may not be needed for the off_github gem to function, but it pays to keep this up to date to prevent any issues with newer gems. Usually, you’ll want Rubygems version 1.3.0 or higher. At the time of this post, the current version is 1.3.5.

$ gem –version
1.2.1
$ [sudo] gem update –system
……
$ gem –version
1.3.5

Once that’s done, install the off_github gem. To do that, add Gemcutter as a source and run the gem install command.

$ gem sources -a http://gemcutter.org
$ [sudo] gem install off_github

Note: Rubyforge gems now points to Gemcutter, so the gem source adding isn’t technically needed to install off_github. That said, the off_github gem still checks for the Gemcutter source (it’s a bit outdated) and won’t work without it, so to get around it, install it before running, and you can remove it afterwards.

Now go ahead and run the off_github command. If you don’t use sudo to install gems, then be sure to add –no-sudo the end.

$ off_github [--no-sudo]

This’ll go ahead and return a list of gems that were installed from Github, what there Gemcutter gem name is, and the action it’ll take on that gem (usually reinstall). It’ll then ask you if you want to install. Type ‘Y’, hit enter, and then choose y/n/a at each prompt.

If everything went smoothly, you’re all done. You can now go ahead and delete both the Github and Gemcutter sources.

$ gem sources -r http://gems.github.com
$ gem sources -r http://gemcutter.org

So know, you should have Rubyforge as your only gem source.

$ gem sources
*** CURRENT SOURCES ***
http://gems.rubyforge.org

Additional Material:

• http://www.rubypulse.com/episode-0.16_off_github.html
• http://www.rubypulse.com/episode-0.16.1_off_github_revisited.html