Live data from Hacker News

Rails 3 Performance - Not Good Enough

blog.tstmedia.com

1–10 of 142 posts

Re: Rails 3 Performance - Not Good Enough

#6
post #2

I'd be interested to know if they are running Rails 3 on 1.9.2 or 1.8.7.

They said they were using ruby enterprise edition (aka a 1.8.6 branch)

Interesting, IIRC Rails 3 works best with 1.9.2 I'm going to run the benchmarks on 1.9.2 vs. 1.8.7 and see how they fare.

Re: Rails 3 Performance - Not Good Enough

#8
post #2

I'd be interested to know if they are running Rails 3 on 1.9.2 or 1.8.7.

They said they were using ruby enterprise edition (aka a 1.8.6 branch)

The article mentions, "REE 2011.03, which is Ruby 1.8.7 patchlevel 334". Not sure if this was a recent edit or not.

Re: Rails 3 Performance - Not Good Enough

#9
The benchmark was done using REE. Out of curiousity, I tried it with MRI 1.8.7, MRI 1.9.2, and REE 1.8.7. Results are best out of three:

                    user     system      total        real
  rails3-1.9.2  2.240000   0.200000   2.440000 (  3.127072)
  rails2-ree    2.530000   0.290000   2.820000 (  3.578471)
  rails2-1.8.7  2.920000   0.210000   3.130000 (  3.876215)
  rails3-ree    3.140000   0.250000   3.390000 (  4.111465)
  rails3-1.8.7  3.560000   0.220000   3.780000 (  4.505166)
Of course, the author was looking into a specific problem — this doesn't mean that Rails 3 on MRI 1.9.2 is faster than Rails 3 on REE.

Run on an iMac9,1 with a 2.66 GHz Core 2 Duo. uname -a:

Darwin Roy.local 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386

I disabled spotlight, but who knows what other processes might have spawned in the middle of the benchmark. Your mileage may vary.

Re: Rails 3 Performance - Not Good Enough

#10
There clearly still are performance problems in Rails 3.0.x that aren't fixed. I am just now in the process of switching an application to Rails 3 and I have recently spent 5 days of hard work trying to investigate a big performance drop after the migration (under a different environment: Ruby 1.9.2 and PostgreSQL). I ended up finding two big performance issues in Rails PostgreSQLAdapter:

https://github.com/rails/rails/issues/398 https://github.com/rails/rails/issues/485

What they and everyone else experiencing performance problems should do, is to find one action that has the biggest performance difference between running under Rails 2 and Rails 3 and then profile it - easiest way is by wrapping the action in an around filter and using RubyProf. If there is a obvious performance problem somewhere, you will most often see a method that has a really huge number of calls and %self% time in comparison to all the others. Then you have to figure out what in detail happens - I ended up doing this by putting "begin; raise StandardException.new; rescue => e; puts e.backtrace; end;" into the "hot" methods to get call stacks and then went on to read the code involved.

Post reply on HN