I was excited when I heard that Ruby 1.9.3 was going to halve the startup times for apps that have many, many "require" statements (such as Rails apps), compared to 1.9.2. Unfortunately, after the upgrade, the startup times for my Rails 2.3.14 app are as bad as ever. It takes 50 seconds to get to a prompt after executing "script/console". In that time, it executes 1499 "require" statements.
My question is, how do I get it to start up faster?
I used the following code snippet at the top of my environment.rb file to log all the require statements:
module Kernel
def require_new(fn)
puts "#{Time.now.strftime('%Y-%m-%d %H:%M:%S')} #{fn}"
require_old(fn)
end
alias_method :require_old, :require
alias_method :require, :require_new
end
Imho Ruby 1.9.3 is pretty slow out of the box. What could you do to improve the perfomrance is:
Apply the falcon patch if you're using p0. Here you'll find how:
https://gist.github.com/1688857
including the bonus of tuned up environment variables.
Get the freshly baked out Ruby 1.9.3-p125 http://www.ruby-lang.org/en/news/2012/02/16/ruby-1-9-3-p125-is-released/ I checked it, and my first impression is that the performance is greater than p0.
Upgrade Rails, like user shingara mentioned in the comments.
Related
I have a small rails app, which was running fine with Ruby 1.8x and Rails
2.x. In a regrettable decision, I decided to move to Ruby 1.9.x and Rails 3,
and it's a glorious pain.
My Ruby app uses MySQL, and I use Active Record for that.
However there is an earlier pgm I had written to fill in the database
before I did Rails (2.x), which is part of the complete application now.
(I can test/run the standalone pgm outside Rails and there is no
problem.)
This standalone program is using MySQL and dbi gems. I call this program as such from a model:
system("ruby standalonepgm.rb -args ")
In Rails 2.0 this works without any issues.
In 3.0 the program exits without any way to capture the error.
Running under console I see that the program dies because it can't find the
dbi gem!
If I put the dbi gem in the Gemfile and do bundle date, then there is
real trouble. Rails refuses to start - the rails server dies with all kind of issues.
I can put in the screendump, but I think that's unimportant.
There seem to be 2 issues:
DBI is surely incompatible with the gods of Rails
Rails creates a sandbox, and all programs called must live in that
sandbox (that's why just a require statement doesn't suffice .. it has to be in Gemfile).
Is it fixable or I am one of those who got bitten by the hidden black magic of rails, and my past 8+ weeks of effort is down the tubes?
It's fixed by using
Bundle.with_clean_env do
system("ruby pgm.rb"
end
I had never read bundle doc ..this case is described in it ..
I'm newish to rails, and I started with rails 3 and ruby 1.8.7
I'm not sure exactly why I went with 1.8.7, but I think it was because many gems are not supported with 1.9.
Was my analysis wrong and I can move to 1.9?
What are things to consider moving to 1.9? Is rails 3 ready for it?
I've moved to 1.9.2 about two months ago and so far everything seems OK. 1.9 is largely backwards-compatible so most things are not a problem.
That said there are two possible sources of significant annoyance when going to 1.9:
CSV parsing. Ruby switched internally to FasterCSV but doing require 'fastercsv' will result in an error. This will require changes to your code if you are doing any CSV parsing.
Encoding changes. If your code (not data) includes non-ascii characters your app will fall apart. The fix is not hard, you have to put the magic comment # encoding: utf-8 on top of any such files, but again a possible source of pain.
All gems I've been using work fine (except those doing CSV).
The only real way to find out for your application is to use rvm and install 1.9.2. Upgrade all of your gems using Bundler and then run all of your tests. Manual testing of the application will ferret out any remaining issues that are not common and specific to your code and data.
I just got burned because I used find_index on an array on my dev box (OSX with Ruby 1.8.7) and the deployment machine runs Ruby 1.8.6. (What's the difference between find_index and index? The latter works on 1.8.7 and 1.8.6)
So that got me thinking: what's the best way to force Rails to run with a specific Ruby version?
Since it's probably relevant (install multiple rubys!), I need to know this for OSX, but it would be useful to know for Linux, Windows, and Commodore 64 as well.
Later: Of course I'm working in a virtual appliance now, but I'd like to be able to control my Ruby versions if possible on my computer.
Note: I don't care too much disallowing Rails running with the wrong Ruby version. I'm more interested in getting the RIGHT ruby version to run. Sorry for the confusion.
This won't force the version of ruby required but you may want to utilize something like RVM to easily manage your ruby environment on your dev and production boxes.
http://rvm.io/
This allows you to easily switch and maintain multiple versions of ruby on your system.
This is brute force and ignorance, but one approach would be
raise "Wrong ruby version, please use ruby 1.8.7" unless RUBY_VERSION == "1.8.7"
Use the RUBY_VERSION constant in your Application controller.
This shows rendering the 500 error page. You would want to setup a new page in your public dir with an appropriate message.
before_filter :check_ruby_version
def check_ruby_version
unless RUBY_VERSION == "1.8.7"
render :file => File.join(Rails.public_path, '500.html'), :status => 500
end
end
Another way to look at the problem would be to be able to disregard differences in the version of Ruby you're running. My backports gem brings Ruby 1.8.6 up to date in the 1.8.x line (including the upcoming 1.8.8) and much of 1.9:
require "backports"
Or instead, for the less courageous among us, you can require only 1.8.7's features:
require "backports/1.8.7"
About half a year ago, when I started to learn Ruby and Rails, I first tried Ruby 1.9 but I soon gave up, because at that time nothing worked out of the box and almost every helping blog or tutorial was designed for Ruby 1.8.
What about now? (Dec 2009) Is it possible to get an existing Rails application running by a Ruby and Rails beginner without running into problems which can only be fixed by an absolute Ruby and Rails professional?
Unfortunately I dind't have good experiences with Ruby 1.9 and Rails.
You can read more here: Has anyone successfully deployed a Rails project with Ruby 1.9.1?
My opinion is that migrating an existing Rails app from Ruby 1.8.x to Ruby 1.9.1 is not as easy as you would think, event with an excellent test suite.
I'm also quite sure that most of the problems arise from trying to convert an existing application because you are working with an established code base.
Starting with a new Rails app with Ruby 1.9 should probably easier because you can trace a problem as soon as you write a single line of code so you can easily isolate which component is not compatible.
When migrating an existing app I had hard time trying to figure out which stack level was actually not compatible with Ruby 1.9. And there are more than one incompatible libraries at the same time I can't tell you how it's difficult to understand which one should be fixed first and which one originated the final error.
In 99.9% of the cases yes, there were rare cases where u might find problems but they should be solved with the new release.
As for the external gems and plugins, most of them now are fully compatible with ruby 1.9, however sepcial cases might exist but I'm not aware of any right now.
I will have to use JDBC with an old database, which I why I selected jRuby. If I get a book on ruby on rails that does not include jRuby information, will that be benficial to me?
Yes it will. Jruby is just another Ruby implementation, so pretty much everything that works in regular Ruby will work in Jruby as well. They have worked very hard at getting rails to run really well with Jruby While there are some gems that currently will not run in jruby, a Ruby On Rails book will definitely be relevant.
One thing to keep in mind though is you cannot run native (C code) gems with JRuby. However most of the popular ones have ports.