Ruby Enterprise Edition VS Ruby 1.9

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.

Ruby Enterprise Edition vs Ruby 1.9.2 memory improvements

The short answer to your question is that many of those improvements are "not necessary in 1.9."

The long answer is to read this blog post from Phusion (the people behind Passenger and REE).

Ruby 1.9.1 or Ruby 1.8.7 Enterprise Edition on a small VM?

The 1.8.7 EE would be a safer bet right now. The main problem with Ruby apps is the distinct inability to share memory (the copy-on-write issue) and fixing that is the main aim of EE.

I manage 8 different sites, all running versions of our product running on a mix of Rails, Merb, Rack and Thin on all running on plain old Ruby 1.8.7. For a small Rails application, 256Mb would be ok.

You can see from below that our application is comprised of 6 processes; Rails (2) and Merb (4). The Rails processes (mongrel_rails) are using 104Mb of actual memory each. Our app is reasonably complex with responses of the order of 0.5s so we are looking at being able to handle around 4/5 concurrent users from the 2 Rails processes. Take a look at the shockingly small amount of shared memory to see why EE makes so much sense. I'd expect a much higher shared section with EE.

As they say 'your experience may differ' but there's nothing stopping you from even trying plain old Ruby/Rails and only moving to EE if you need to.

top - 08:57:48 up 128 days, 11:57,  1 user,  load average: 0.07, 0.09, 0.09
Tasks:  76 total,   1 running,  75 sleeping,   0 stopped,   0 zombie
Cpu(s):  2.4%us,  0.1%sy,  0.0%ni, 96.2%id,  0.0%wa,  0.0%hi,  0.0%si,  1.3%st
Mem:   1048796k total,   745840k used,   302956k free,     5192k buffers
Swap:  2097144k total,   634636k used,  1462508k free,   124816k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                 
25875 root      20   0  271m 104m 4616 S    0 10.2 141:07.07 mongrel_rails                                                                            
25872 root      20   0  263m 102m 4648 S    0 10.0 142:11.86 mongrel_rails                                                                            
21089 root      20   0  192m  84m 2436 S    0  8.3   2:52.03 merb                                                                                     
21088 root      20   0  173m  80m 2436 S    0  7.9   2:51.73 merb                                                                                     
21090 root      20   0  179m  74m 2436 S    0  7.3   2:42.83 merb                                                                                     
21086 root      20   0  113m  34m 1660 S   11  3.4   3752:37 merb                                                                                     
 4874 clavis    20   0  122m  31m 3804 S    0  3.1 127:52.87 profile_report                                                                           
 3662 mysql     20   0  368m  22m 3280 S    0  2.2 464:01.81 mysqld

What is latest ruby on rails enterprise edition?

No, the last REE is based on 1.8.7. The technical improvements made in 1.9 / 2.0 made it unnecessary to continue maintaining a separate 'Enterprise Edition' fork. A brief explanation can be found here (see End of Life section).

If you are finding that 1.9.3 is slow, you can try patching with the back-ported GC improvements to 2.0 (along with some other modest improvements) - see here for how you can do this. However, all this assumes that the slowdown is due to ruby itself and not due to the code, architecture, or server overhead...

Ruby 1.8.7 vs Ruby enterprise

if you are using rvm to develop, you can run your apps unit/functional and acceptance tests against multiple rubies and get an idea how your app will deploy under any interpreter.

https://rvm.io/set/tests/

Rails 3 (Ruby 1.9.2 vs 1.8.6) and (MRI vs REE vs JVM) -- comments/suggestions?

If you're running on windows, my personal recommendation is go with JRuby. MRI (both 1.9.x and 1.8.x) has mountains of problems on windows, whether deploying to XP, Vista, or Windows 7. I don't develop on Windows often, but I do teach Rails classes, and that's my recommendation to Windows students now. Haven't had many issues with JRuby at all, aside from needing to use a different database driver (the jdbc gem versions). RVM doesn't work on windows, but you can use pik (https://github.com/vertiginous/pik) to achieve many of the same goals.

Ruby Enterprise Edition giving Time.now in wrong format

This is not a REE issue. Ruby 1.9.2 changes the default format for Time#to_s.

$ rvm use 1.8.7
ruby-1.8.7-p334 :001 > Time.now
# => Thu May 12 12:42:35 +0200 2011 

$ rvm use 1.9.2
ruby-1.9.2-p180 :001 > Time.now
# => 2011-05-12 12:42:44 +0200

It's a good practice to never rely on the default Time#to_s format but always use a custom helper or method to format a date output otherwise you have no control on how the information are displayed.

Formatting the time using strftime in every single query is not an option at the moment

Not only it should be an option, it should have been your first choice. I strongly encourage you to fix the existing code to use a custom formatting method.

A temporary workaround would be to override Ruby 1.8.7 Time#to_s method to use a custom format. However, making such this change might break other libraries.