Is anyone else seeing significantly worse performance after upgrading an app to Rails3?
Two datapoints after upgrading an app:
an action that averages ~550ms in Rails2.3.5 averages nearly twice as long (1020ms) in Rails3beta2.
startup time is much longer in Rails2. To demonstrate, I’m using runner:
~/projects/rails/tempo(master) $ time ruby script/runner ‘puts “Rails 2 here”’
Rails 2 here
real 0m2.366s
~/projects/rails/tempo(rails3) $ time rails runner ‘puts “Rails 3 here”’
Rails 3 here
real 0m12.053s
That’s 5x longer for Rails 3. Same app, same Ruby version (1.8.7p249). Anyone seeing something similar, or (hopefully) better?
Con
April 4, 2010, 6:16pm
2
Is anyone else seeing significantly worse performance after upgrading an app to Rails3?
Two datapoints after upgrading an app:
an action that averages ~550ms in Rails2.3.5 averages nearly twice as long (1020ms) in Rails3beta2.
startup time is much longer in Rails2. To demonstrate, I’m using runner:
Rails 2.3.5:
~/projects/rails/tempo(master) $ time ruby script/runner ‘puts “Rails 2 here”’
Rails 2 here
real 0m2.366s
Rails 3beta2:
~/projects/rails/tempo(rails3) $ time rails runner ‘puts “Rails 3 here”’
Rails 3 here
real 0m12.053s
That’s 5x longer for Rails 3. Same app, same Ruby version (1.8.7p249). Anyone seeing something similar, or (hopefully) better?
Andre, Rails 3 is still currently in beta. Thus, the Rails core team are still fixing relevant bugs, cleaning up overall functionality, and
the optimizations will come. Also, Rails 3 performs much better with Ruby 1.9.2 than 1.8.7 but your mileage will vary depending on
your platform. In short, Rails 3 beta has been deployed into many production environments but it hasn’t been released as production
ready system. The release candidates (RC) should be coming soon after the beta period which will be fully optimized for running your
performance tests before we see a final release.
Good luck,
-Conrad
ps: I’m basing this information on previous releases of Rails where we go through the following phases: alpha, beta, release candidate,
and final. Thus, the software development work flow may or may not have changed for this version of Rails.
I believe this is a bundler issue. I had the same issue and tracked it
down to Bundler.require which does the gem resolution and seems to
take *forever* with it.
If you run `bundle lock`, I believe it will be significantly faster
again. This does all the gem resolution up front so all bundle has to
do is include all the requires and go.
This thread is quite interesting. I'm curious to see how all this
plays out after the RCs and when optimization has been taken into
account... Thanks for posting this.
You're right -- startup improves quite a bit when you bundle lock:
~/projects/rails/tempo(rails3) $ bundle lock
~/projects/rails/tempo(rails3) $ time rails runner 'puts "Rails 3 w/
bundle lock"'
Rails 3 w/bundle lock
real 0m3.854s
user 0m3.043s
sys 0m0.535s
~/projects/rails/tempo(rails3) $ bundle unlock
~/projects/rails/tempo(rails3) $ time rails runner 'puts "Rails 3,
not locked"'
Rails 3, not locked
real 0m9.952s
user 0m8.486s
sys 0m1.181s
That's better than twice as fast with bundle lock. This project uses
relatively few gems, so presumably a project with more gems would show
an even greater disparity between locked and unlocked gems.
Even with locked gems, Rails3b2 startup is slower than 2.3.5 startup.
It's tolerable though - about a second difference. Back to Rails
2.3.5:
~/projects/rails/tempo(master) $ time ruby script/runner 'puts "Rails
2 here"'
Rails 2 here
real 0m2.668s
user 0m1.882s
sys 0m0.338s
Jacques, thanks for the pointer!
Con
April 4, 2010, 11:40pm
6
If you run bundle lock, I believe it will be significantly faster
again. This does all the gem resolution up front so all bundle has to
do is include all the requires and go.
You’re right – startup improves quite a bit when you bundle lock:
~/projects/rails/tempo(rails3) $ bundle lock
~/projects/rails/tempo(rails3) $ time rails runner 'puts "Rails 3 w/
bundle lock"’
Rails 3 w/bundle lock
real 0m3.854s
user 0m3.043s
sys 0m0.535s
~/projects/rails/tempo(rails3) $ bundle unlock
~/projects/rails/tempo(rails3) $ time rails runner 'puts "Rails 3,
not locked"’
Rails 3, not locked
real 0m9.952s
user 0m8.486s
sys 0m1.181s
That’s better than twice as fast with bundle lock. This project uses
relatively few gems, so presumably a project with more gems would show
an even greater disparity between locked and unlocked gems.
Even with locked gems, Rails3b2 startup is slower than 2.3.5 startup.
It’s tolerable though - about a second difference. Back to Rails
2.3.5:
~/projects/rails/tempo(master) $ time ruby script/runner 'puts "Rails
2 here"’
Rails 2 here
real 0m2.668s
user 0m1.882s
sys 0m0.338s
Rails 3 locked/unlocked on my system takes less than .75 seconds on average.
Good luck,
-Conrad
Conrad, Rails3 starts up in .75 sec for you? For comparison purposes,
how many gems does our project include? What version of Ruby are you
on?
My project uses only a few gems -- rails, authlogic, haml, mysql, and
thin. Its Ruby 1.8.7p249 on a 2.2Ghz MBP.
Con
April 5, 2010, 5:15am
8
Rails 3 locked/unlocked on my system takes less than .75 seconds on average.
Conrad, Rails3 starts up in .75 sec for you? For comparison purposes,
how many gems does our project include? What version of Ruby are you
on?
Andre, I have about 15 gems within my project. Also, I’m using Ruby 1.9.2 from
trunk. Next, I’m using a MacPro 2.9 GHz 8-core with 32 GB RAM. Lastly, Rails 3
performs best with Ruby 1.9.2.
Good luck,
-Conrad