I’ll answer that with a screenshot:
We upgraded from Ruby 1.9 to 2.1 in production about a week ago, and this is what we saw. The gray section at the bottom is our garbage collection time going to almost nothing. Overall, the upgrade gave us a 15-20% improvement in server response time. That’s without doing any additional GC tuning!
We saw a big boost in Google’s and Bing’s crawl rates after shipping the upgrade, which is especially awesome for sites like ours that benefit heavily from search engine traffic.
Cool, so how hard was it?
On a large Rails app with close to 150 gem dependencies, the upgrade took a single small commit and a few days of testing. We run rvm on all of our servers and provision with chef, so upgrading all our servers to 2.1 was as simple as changing a version number in a chef role file.
What problems did we run into?
We still use iconv for transliteration, so we had to include the
iconv gem, which replaces built-in
functionality that was removed from 2.x. I was never able to get
ruby-debug or the
debugger gem working under 2.x,
so we switched to pry and
still prefer the debugger gem to pry-byebug, but pry is so much better
than irb that it’s kind of a wash. Deivid Rodriguez,
byebug’s author, pointed out that my problems with pry-byebug were
probably not caused by byebug. He was totally right! (it was actually
caused by the interaction between byebug and pry).
In a mixed 1.9 and 2.1 environment, you’ll also have to upgrade bundler to 1.5.1. With the new version of bundler, you can specify 2.1 as a platform requirement in your Gemfile:
It sounds like GitHub ran into some other problems with 2.1, mentioned by Aman Gupta in this gist: https://gist.github.com/tmm1/8393897, but we haven’t noticed any issues yet.
You’ll also want to tune the GC after you ship to get even more speed. Aman has a good post with lots of details on how to do that: http://tmm1.net/ruby21-rgengc/. The entire 2.1 series on his blog is worth reading if you want to get the most benefit from your cheap, simple Ruby upgrade.