Has Anyone Successfully Deployed a Rails Project with Ruby 1.9.1

Has anyone successfully deployed a Rails project with Ruby 1.9.1?

Matz recently spoke at RubyFoo in London about ruby 1.9.1 adoption. Quite simply, ruby 1.9.1 is not production ready and should not be used for deployment just yet.

Ruby 1.9.2 will be production ready, but until then you should only use ruby 1.9.1 for play and testing.

Although many people out there have had successful deployments using 1.9.1, I would recommend sticking with REE 1.8.7 until 1.9.2 is out. Rails 3.0 will favor 1.9.2, but also work quite happily with 1.8.7 (it will NOT work with 1.8.6).

Is Ruby 1.9.1 actually ready and faster for a new Rails deployment?

We experimented with 1.9 a couple months ago and we were so impressed by the speed improvements that we almost immediately began the process of migrating over to it. The only libraries that did not run smoothly were Facebooker, which one of our developers was able to patch in a couple of days (The plugin is now fully 1.9 compatible), and VPim (iCalendar library) which we were able to switch out easily with the much newer RiCal plugin.

Rails 2.3 is absolutely ready to run on 1.9 and in our experience resulted in a greater than 60% improvement in request times. Our integration tests also received the same benefit. We had 1200 tests that tool 300 seconds to run now taking only 110 seconds with no other changes except switching from Ruby 1.8.7 to Ruby 1.9.1. This also means we were able to double the amount of load each of our servers could handle.

It's certainly possible that you use a gem that is not 1.9 compatible, but the vast majority of them are or can be made compatible with minor changes.

You will definitely not experience any issues with 75,000 unique visitors, and a single server should be able to host a rails application with at least ten times that level of traffic unless your application is written very poorly.

Can Ruby 1.9 used with Rails by a Ruby/Rails beginner?

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.

Ruby 1.9.1-p234, Passenger 2.2.5, Rails 2.3-stable closed stream on POST request

There is a workaround in passenger 2.2.8 so this is no longer needed.

Casual Jim's response above worked for me. Thanks very much Jim for your help.

The diffs on my system are, respectively, as follows. I hope this is helpful.

Killian.

*** /usr/local/lib/ruby/gems/1.9.1/gems/passenger-2.2.5/lib/phusion_passenger/utils.rb.orig Tue Nov  3 17:43:30 2009
--- /usr/local/lib/ruby/gems/1.9.1/gems/passenger-2.2.5/lib/phusion_passenger/utils.rb  Tue Nov  3 17:43:46 2009
***************
*** 31,36 ****
--- 31,37 ----
  require 'etc'
  require 'fcntl'
  require 'tempfile'
+ require 'stringio'
  require 'phusion_passenger/exceptions'
  if !defined?(RUBY_ENGINE) || RUBY_ENGINE == "ruby"
    require 'phusion_passenger/native_support'


*** /usr/local/lib/ruby/1.9.1/tempfile.rb.orig  Tue Nov  3 17:44:34 2009
--- /usr/local/lib/ruby/1.9.1/tempfile.rb   Tue Nov  3 17:45:55 2009
***************
*** 137,143 ****
      # keep this order for thread safeness
      begin
        if File.exist?(@tmpname)
!         closed? or close
          File.unlink(@tmpname)
        end
        @@cleanlist.delete(@tmpname)
--- 137,143 ----
      # keep this order for thread safeness
      begin
        if File.exist?(@tmpname)
!         # closed? or close
          File.unlink(@tmpname)
        end
        @@cleanlist.delete(@tmpname)

Encoding problems in rails on ruby 1.9.1

I just had this as well so I think its worth having the correct answer.

The 2.8.1 MySql gem is not utf-8 friendly, so it sometimes will return UTF strings and lie to Rails, telling it that they are ASCII when in fact they are UTF-8. This makes things explode.

So: you can either monkey patch or get a compatible MySql gem. See: http://gnuu.org/2009/11/06/ruby19-rails-mysql-utf8/

Should I use Ruby 1.9.2 with my new web app?

I have been successfully converting all my Rails projects (except one, but I'm working on it) from Ruby 1.8.7/Rails 2.3.5 to Rails 3.0.0 and Ruby 1.8.7/1.9.2 RC2 and both environments are pretty stable.

Fortunately, things changed since I posted this question.

Rails

Unless you really have something that prevents you to do that, I strongly encourage you to start with Rails 3.
The effort required to upgrade an application from Rails 2 to Rails 3 should discourage you from starting from Rails 2.

Talking about plugins and Gems, many developers are starting to convert their libraries to Rails 3. Currently there's a very high level of compatibility.
Furthermore, Rails 3 focused plugins tends to be quite more powerful to the Rails 2.3 ones, thanks to the new Rails plugin API. They can load tasks, they no longer abuse monkey patching or rely on internal hacks.

Also, Rails 3 is just around the corner. Unless your project will be deployed in 1 week, the stable version will probably available before you deploy your code.
I this would not happe, consider that I'm currently managing a couple of Rails 3 project in a production environment and they are pretty stable (Rails 3 RC1, the Beta 4 has a really weird bug in the caching environment).

Ruby 1.9.2

Ruby 1.9.2 is way more powerful than Ruby 1.8.7. If this is a brand new project, I suggest you to use the 1.9 branch.

Usually, it's more easy to start a new project in Ruby 1.9 than converting an existing one.

Ruby 1.9.2 is faster, even more faster than REE. The most part of the common Ruby 1.8.7 Gems work with Ruby 1.9 except a few ones, such as RCov.
Again, it's very hard you're going to need a library which doesn't work with Ruby 1.9.2.

If it happens, chances are this is an outdated library and a better replacement is probably available in the Ruby ecosystem.

If you can't find an alternative, remember that Rails 3 provides an excellent way to use custom libraries, thanks to Bundler.
You can fork the project and ask Bundler to use your fork. You can even integrate the library in your repos and ask Bundler to load the library from a path.

Conclusion

From my personal experience, I've been very happy with Ruby 1.9.2 and Rails 3.
This is by far my favorite environment and my default environment for new projects.

If you can't use Ruby 1.9.2 try with Ruby 1.8.7.
On the other side, I strongly encourage you to start with Rails 3.

Ruby version is not upgrading on Heroku

I didn't read the documentation with enough attention.

My heroku PATH was

vendor/bundle/ruby/1.9.1/bin:/usr/local/bin:/usr/bin:/bin

The documentation says:

If absent or not the first entry, add bin: to the config with heroku
config:add. $ heroku config:add
PATH=bin:vendor/bundle/ruby/1.9.1/bin:/usr/local/bin:/usr/bin:/bin

Not the first entry term (not simply present as I thought), obviously I needed to add the 'bin' in front of the PATH.

Ruby Enterprise Edition vs Ruby 1.9

REE from my experience has a tendency to throw mallocs in odd places (Jan 2009 tab completion in script/console - https://webrat.lighthouseapp.com/projects/10503/tickets/89-excessive-output-caused-by-and-only-by-running-webrat).

Ruby 1.9.1 has a massive bug in tempfile which blows up Rack (August 2009 present in patchlevel 243 - http://groups.google.com/group/rack-devel/browse_thread/thread/a2aab3a4720f34c4?pli=1). As well as this I do not believe Ruby 1.9.1 to have been tested properly with Rails 2.3.4 (String exclusive or - https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/3144-undefined-method-for-string-ror-234).

Quite honestly, it depends on how well you react to surprises. I use an old patchlevel of 1.9.1 on a server running 2.3.3 and other than a patch in Net::HTTP to work with ActiveResource, it runs blazingly fast.

If you don't like surprises, stick to 1.8.7.

Update 10/10/2010

The answer to my question is invalid nowadays, both Ruby EE and 1.9.2 are very good implementations of Ruby!

I'm not quite sure which one I would pick, probably 1.9.2 - or hold out to say what the phusion guys are working on, since they are working on a 1.9 version of REE - but, their 1.8.7 REE is pretty solid.

---

Related Topics