Phusion white papers Phusion overview

Ruby Enterprise Edition 1.8.7-20090928 released

By Hongli Lai on September 29th, 2009

In the not so distant past we launched a Ruby Enterprise Edition sponsorship campaign. We’ve been working hard on the code since that time. And although the campaign target hasn’t been reached, we’ve decided to release it anyway because we believe that this release is of great importance to the community.

Just how important is this release? Well, Twitter has beta tested this release and they’re reporting roughly 30% improvement in throughput. Keep reading to learn more and follow us on @phusion_nl for the latest updates.

Summary of changes

It’s now based on Ruby 1.8.7-p174

Previous REE releases were based on 1.8.6. We were initially reluctant about switching to 1.8.7: many people reported various incompatibility problems introduced by 1.8.7, and it seemed that alternative Ruby implementors were boycotting 1.8.7. However, the tide has now changed. Rails 3.0 will drop support for Ruby versions earlier than 1.8.7, JRuby had recently decided to support 1.8.7 and OS X Snow Leopard as well as all the Linux distros ship 1.8.7. We’ve received a lot of requests from the community for a 1.8.7-based version.

In short, everybody is moving towards 1.8.7, and we can’t afford to stay behind.

We were initially planning to release a final 1.8.6-based version, but after carefully considering the current state of things, we decided to skip the 1.8.6 release and jump directly to 1.8.7. 1.8.7 is also more compatible with 1.9, allowing a smoother transition to future Ruby versions.

The MBARI patches have been integrated
Brent Roman’s MBARI patch set uses a variety of techniques to significantly reduce Ruby’s memory usage. It also adds a bunch of performance optimizations, useful features and bug fixes.

  • Ruby’s garbage collector scans the C stack conservatively. This means that any data on the C stack that might look like a pointer pointing to a valid Ruby object will be treated like a real pointer, causing the object to be retained during garbage collection. Because of the way Ruby is written and because of compiler optimizations, there may be a lot of such “pointers” on the stack, even when they’re not really pointers but just garbage data that like look pointers.

    Brent has refactored and modified many parts of Ruby in order to reduce the possibility of such “garbage pointers” occurring on the stack. As a result, garbage collection will be much more effective. Many objects that would otherwise not have been freed will be freed thanks to the MBARI patches.

    As a side-effect of the reduced memory usage, applications typically run faster as well. Not only because applications are less likely to be swapped out, but also because modern hardware’s performance depends greatly on the amount of memory traffic.

  • Ruby uses an inefficient, linear time algorithm for extending the stack space when switching context between threads and/or continuations. This is mostly noticeable when you have a lot of threads. Brent replaces this with a constant time algorithm, which is much faster.
  • It adds the methods __file__ and __line__ to the Method, UnboundMethod and Proc classes. Very useful for inspecting large code bases that make heavy use of metaprogramming. These methods are documented in the Ruby Enterprise Edition manual.

We’ve ported his patch set to 1.8.7-p174. Especially Twitter benefited a lot from these patches.

The zero-copy context switching patch have been integrated as an optional feature
Joe Damato and Aman Gupta have created a patch which implements zero-copy context switching in Ruby’s threading system. In Ruby 1.8, whenever Ruby switches context to another thread, it has to copy over the entire thread stack. This is very expensive, and the deeper your function calls are nested, the slower it becomes. The zero-copy context switching patch removes the need to copy any stack data; instead, it keeps all thread stacks at different areas in memory and simply changes the stack pointer. In extreme situations, this patch can increase threading performance by as much as 10 times!

Phusion Passenger is not really affected by this patch because its request handling core is not multithreaded, at least not at this moment. But Mongrel is heavily multithreaded and will benefit tremendously from this patch.

We’ve made this patch compatible with the MBARI patch set, but there are currently some issues with 64-bit platforms, so we’ve disabled it by default. You can enable it by running the REE installer with --fast-threading

Various other minor changes
  • When compiling REE, binaries are optimized for size (-Os), not speed. See below for an explanation.
  • The tcmalloc memory allocator has been upgraded to version 1.3
  • RubyGems upgraded to version 1.3.5.
  • The Debian package now installs files to /usr/local, so that one doesn’t have to mess with $PATH to get things working.

In practice

This release has been beta tested with Twitter. Evan Weaver reported significant improvements in Twitter’s throughput after having switched to this REE release.

REE benchmark by Twitter

Twitter especially benefited from the MBARI patch set. We’ve found a few unexpected things during the beta testing phase:

  • We’ve found that optimizing Ruby for code size (compilation with -Os) yields better results that optimizing Ruby for speed (compiling with -O2). Ruby is a very unconventional program and we suspect that optimizing for code size allows more instructions to fit in the CPU instruction cache, resulting in better performance.
  • Microbenchmarks and synthetic benchmarks such as the Ruby benchmark suite do not show any performance improvements at all, although Twitter was able to measure a significant performance improvement. As always, benchmark results should be taken with a grain of salt.

Other major beta testers include 37signals and Novell. They’re still in the progress of testing, and we’re eager to receive their test results.

Sponsors

Special thanks go out to LVS for acting as a gold sponsor for this release:

LVS has been building and supplying enterprise platforms for the betting and gaming industry in South East Asia, Europe and the UK for more than 10 years. The team at LVS is a balanced mix of gaming industry specialists, technical experts and entrepreneurial leaders. With offices in London and Gibraltar we directly employ over 40 staff.

Our Advanced Betting Platform (a fully internationalized and localized high-availability platform based on Java and Ruby on Rails) is now regarded as the most technically advanced sports book system available in the World, and has been customised to fit the requirements of companies like Victor Chandler in Gibraltar and La Française des Jeux in France.

LVSLogo

We also thank the following people and organizations for sponsoring this release:

Download & upgrade

To install Ruby Enterprise Edition, please visit the download page. To upgrade from a previous version, simply install into the same prefix that you installed to last time. Please also refer to the documentation for upgrade instructions.

UPDATE: Snow Leopard support

It looks like tcmalloc has some issues on Snow Leopard, causing the compiler to crash. We’ve just been able to obtain Snow Leopard last weekend (it had been sold out for several weeks) and we haven’t gotten around installing it yet.

To install REE on Snow Leopard, you should run the installer with --no-tcmalloc

Ruby Enterprise Edition 1.8.6-20090610 released: fixes BigDecimal DoS vulnerability

By Hongli Lai on June 10th, 2009

A denial of service vulnerability in Ruby had been found. An attacker could supply a large value to BigDecimal, causing the Ruby interpreter to crash. The following versions of Ruby are affected:

  • Ruby 1.8.6-p368 and all prior versions
  • Ruby 1.8.7-p160 and all prior versions
  • Ruby Enterprise Edition 20090520 and all prior versions

The following code demonstrates the problem:

require 'bigdecimal'
BigDecimal("9E69999999").to_s("F")

We are releasing Ruby Enterprise Edition 1.8.6-20090610, which is an emergency release containing a backport of the fix. All users are advised to upgrade. We have tested this release against RubySpec, the Rails 2.3 test suite and the Phusion Passenger test suite, and everything passes.

REE releases are usually hosted on RubyForge, but it’s currently down, so we’re temporarily hosting this release on our own web server. Please note that these links are temporary and will be replaced by RubyForge links once RubyForge is online again. (UPDATE: links point to RubyForge now)

To upgrade from a previous version, simply install into the same prefix that you installed to last time. Please also refer to the documentation for upgrade instructions.

Ruby Enterprise Edition third sponsorship campaign

By Hongli Lai on May 27th, 2009

What is Ruby Enterprise Edition?

Ruby Enterprise Edition (REE) is a server-oriented distribution of the official Ruby interpreter, and includes various additional enhancements, such as:

REE can be easily installed in parallel to your existing Ruby interpreter, allowing you switch to REE with minimal hassle or risk. REE has been out for about a year now and is already used by many high-profile websites and organizations, such as New York Times, Shopify and 37signals.

“We switched to enterprise ruby to get the full benefit of the [copy-on-write] memory characteristics and we can absolutely confirm the memory savings of 30% some others have reported. This is many thousand dollars of savings even at today’s hardware prices.”
Tobias Lütke (Shopify)

And just like Phusion Passenger, Ruby Enterprise Edition is 100% open source.

Announcing the third sponsorship campaign

A lot of exciting things are happening in Ruby land. On the one hand we have Ruby 1.9, which is not only much faster than Ruby 1.8, but also tends to use less memory and has a better threading model. Although the Ruby libraries ecosystem is quickly catching up with 1.9, there are still many libraries which are not yet 1.9-compatible, preventing many people from using Ruby 1.9 in production environments.

On the other hand, people such as Brent Roman, Aman Gupta and Joe Damato have made exciting improvements to the Ruby 1.8 codebase in the areas of performance and memory usage. Some of these improvements bring parts of Ruby 1.8 on par with 1.9, while other improvements potentially affect 1.9 as well. These 1.8 improvements allow us to enjoy the benefits of having a better, faster and less memory hungry Ruby interpreter in production environments, without sacrificing compatibility.

That said, these patches are not small, and merging them with each other, as well as with all the existing Ruby Enterprise Edition patches, is not a trivial job. We have not only been working with these people for a while now to get their patches incorporated into Ruby Enterprise Edition, but we have also sent them financial contributions in order to thank them for their excellent work.

In order to be able to continue to help people who improve Ruby, as well as to cover our own development expenses and business expenses, we are pleased to announce the third Ruby Enterprise Edition sponsorship campaign. It is thanks to the success of the last campaigns, as well as the generosity of the community, that we are able to do this.

Just like the last campaign, this one is public and everyone can participate. This campaign will cover the following work:

Merging Brent Roman’s MBARI patches into Ruby Enterprise Edition.

Brent Roman’s MBARI patch set uses a variety of techniques to significantly reduce Ruby’s memory usage. It also adds a bunch of performance optimizations, useful features and bug fixes.

  • Ruby’s garbage collector scans the C stack conservatively. This means that any data on the C stack that might look like a pointer pointing to a valid Ruby object will be treated like a real pointer, causing the object to be retained during garbage collection. Because of the way Ruby is written and because of compiler optimizations, there may be a lot of such “pointers” on the stack, even when they’re not really pointers but just garbage data that like look pointers.

    Brent has refactored and modified many parts of Ruby in order to reduce the possibility of such “garbage pointers” occurring on the stack. As a result, garbage collection will be much more effective. Many objects that would otherwise not have been freed will be freed thanks to the MBARI patches.

    As a side-effect of the reduced memory usage, applications typically run faster as well. Not only because applications are less likely to be swapped out, but also because modern hardware’s performance depends greatly on the amount of memory traffic.

  • Ruby uses an inefficient, linear time algorithm for extending the stack space when switching context between threads and/or continuations. This is mostly noticeable when you have a lot of threads. Brent replaces this with a constant time algorithm, which is much faster.
  • It adds the methods __file__ and __line__ to the Method, UnboundMethod and Proc classes. Very useful for inspecting large code bases that make heavy use of metaprogramming.
  • It fixes some crashing bugs in Ruby’s continuations implementation.

Current status: The MBARI patches partially overlap with our copy-on-write patches, but we have been able to successfully merge the two patch sets together. Merging the result with the other patches, e.g. the RailsBench patches which are also included in REE, is still a work-in-progress, but we expect to be finished very soon.

Merging Joe Damato’s and Aman Gupta’s patches into Ruby Enterprise Edition.
Joe Damato and Aman Gupta’s SIGVTALRM patch, which is already included in the latest Ruby Enterprise Edition release, fixes a Ruby thread scheduler bug which degrades performance once the last thread in the application (except the main thread) has exited. This is especially important in applications which are mostly single-threaded, but may occasionally spawn a thread. This includes all single-threaded applications that use the ‘timeout’ library, because it is implemented using threads.

This team has recently also created a patch which fixes the performance degradations that occur when –enable-pthread is enabled, as well as a zero-copy context switching patch. In Ruby 1.8, whenever Ruby switches context to another thread, it has to copy over the entire thread stack. This is very expensive, and the deeper your function calls are nested, the slower it becomes. The zero-copy context switching patch removes the need to copy any stack data; instead, it keeps all thread stacks at different areas in memory and simply changes the stack pointer. In extreme situations, this patch can increase threading performance by as much as 10 times!

Phusion Passenger is not really affected by this patch because its request handling core is not multithreaded, at least not at this moment. But Mongrel is heavily multithreaded and will benefit tremendously from this patch.

Current status: We’ve tested this patch, and it turns out that it breaks continuations. We’re working with the authors to solve this issue. Also, parts of this patch overlap with the MBARI patch set. We are currently working on merging them.

Documenting the implications for REE users.

The MBARI patch set adds a few more API calls for tuning the garbage collector, as well as some configure flags for customizing the manner with which memory consumption is reduced. We will document these things.

Campaign goal and conditions

The goal of this campaign is 9000 USD. We have a surplus of 642 USD from the last campaign, and we’ve already factored in this amount.

Once the campaign goal has been reached, we’ll release the work as soon as it has been finished. Highlights:

  • All sponsors will be given credit on the related REE release announcement on our blog. If the sponsor is an organization then we’ll link to the website, if available.
  • The money that we receive through this campaign shall be treated like donations.
  • An invoice is available if both of the following conditions apply:
    1. You are an organization based in the European Union.
    2. You’ve sent 200 USD or more.
  • If we receive more money than the campaign goal, then the surplus will be used for the next REE sponsorship campaign.

To sponsor this campaign, please click on the following button:
Click here to lend your support to: Ruby Enterprise Edition third sponsorship campaign and make a donation at www.pledgie.com !

Thank you for your continued support!

Ruby Enterprise Edition 1.8.6-20090520 released

By Hongli Lai on May 20th, 2009

What is Ruby Enterprise Edition?

Ruby Enterprise Edition (REE) is a server-oriented distribution of the official Ruby interpreter, and includes various additional enhancements, such as:

REE can be easily installed in parallel to your existing Ruby interpreter, allowing you switch to REE with minimal hassle or risk. REE has been out for about a year now and is already used by many high-profile websites and organizations, such as New York Times, Shopify and 37signals.

“We switched to enterprise ruby to get the full benefit of the [copy-on-write] memory characteristics and we can absolutely confirm the memory savings of 30% some others have reported. This is many thousand dollars of savings even at today’s hardware prices.”
Tobias Lütke (Shopify)

And just like Phusion Passenger, Ruby Enterprise Edition is 100% open source.

Changes

“Virtual timer expired” bug fixed
It turns out that the single threading performance fix (SIGVTALRM patch) that was included in the last release had a bug which caused Ruby to crash with a “Virtual timer expired” error in some circumstances. This problem has been fixed, and our sincere apologies for any inconvenience that this may have caused.
If you were experiencing any crash problems, then please upgrade to this release.
Other changes
There are also some minor documentation and installer improvements.

Download & upgrade

To install Ruby Enterprise Edition, please visit the download page. To upgrade from a previous version, simply install into the same prefix that you installed to last time. Please also refer to the documentation for upgrade instructions.

Hongli Lai Ninh Bui

Ruby Enterprise Edition 1.8.6-20090421 released

By Hongli Lai on April 22nd, 2009

What is Ruby Enterprise Edition?

Ruby Enterprise Edition (REE) is a server-oriented distribution of the official Ruby interpreter, and includes various additional enhancements, such as:

REE has been out for about a year now and is already used by many high-profile websites and organizations, such as New York Times, Shopify and 37signals.

“We switched to enterprise ruby to get the full benefit of the [copy-on-write] memory characteristics and we can absolutely confirm the memory savings of 30% some others have reported. This is many thousand dollars of savings even at today’s hardware prices.”
Tobias Lütke (Shopify)

And just like Phusion Passenger, Ruby Enterprise Edition is 100% open source.

Changes

Now based on Ruby 1.8.6-p287
The previous REE released was based on Ruby 1.8.6-p286. This one is based on p287, which fixes a few bugs in the ‘dl’ library.

Unfortunately there wasn’t enough time to base REE on Ruby 1.8.6-p368, which was released last week. This is planned for a future version.

Fixed a possible infinite looping bug in the garbage collector
A long-standing, but rare, infinite looping bug in the garbage collector has been fixed. If you’ve ever seen Ruby Enterprise Edition freezing while using 100% CPU, then that’s probably this bug. This bug only occurs under very rare circumstances involving deferred running of finalizers.

Users are strongly advised to upgrade to this release for this bug fix alone.

Upgraded to tcmalloc 1.2
The tcmalloc memory allocator has been upgraded from version 0.99.6 to 1.2, which is slightly faster and has support for more platforms.
Upgraded to RubyGems 1.3.2
If you’ve ever seen an error message in Phusion Passenger along the lines of “Directory ‘/nonexistent’ not found”, then what you’ve seen is a bug in RubyGems 1.3.1. This bug has been fixed in RubyGems 1.3.2.
Included Sparc optimization patches
Darryl Gove’s and Miriam Blatt’s Sparc optimization patches are now included. It has been reported that these patches make Ruby significantly faster and more stable on Sparc machines.
OpenSSL extension compilation on Gentoo fixed
The Ruby OpenSSL extension didn’t compile correctly on Gentoo. This issue has been fixed by applying a patch by the Gentoo developers.
Installer improvements
  • The installer now supports command line arguments for disabling the automatic installation of gems and for passing arguments to the Ruby configure script. The latter is useful for enabling –enable-shared, which is required for some libraries such as RubyCocoa.
  • Some Solaris compilation problems have been fixed. Patch by Dana Contreras.
  • The CC, CFLAGS and LDFLAGS environment variables are now respected by the installer itself as well. Patch by Dana Contreras.
Documentation improvements
Evan Weaver has recently published the garbage collector tuning settings used by Twitter. These settings have been included in the documentation along with the 37signals settings.

In our tests, the Twitter settings result in a 12% performance improvement at the cost of a higher memory usage.

64-bit Ubuntu package
We now also provide an x86_64 Ubuntu package.

Download & upgrade

To install Ruby Enterprise Edition, please visit the download page. To upgrade from a previous version, simply install into the same prefix that you installed to last time. Please also refer to the documentation for upgrade instructions.

Hongli Lai Ninh Bui

Ruby Enterprise Edition 1.8.6-20090201 released

By Hongli Lai on February 1st, 2009

What is Ruby Enterprise Edition?

Ruby Enterprise Edition (REE) is a server-oriented distribution of the official Ruby interpreter, and includes various additional enhancements. REE’s main benefits are the ability to reduce Ruby on Rails applications’ memory usage by 33% on average, the ability to increase applications’ performance and the inclusion of various analysis and debugging features. The lower memory usage and increased performance are possible because REE includes – among other enhancements – a copy-on-write friendly garbage collector, as well as an improved memory allocator. REE has been out for several months now and is already used by many high-profile websites and organizations, such as New York Times, Shopify and 37signals.

“We switched to enterprise ruby to get the full benefit of the [copy-on-write] memory characteristics and we can absolutely confirm the memory savings of 30% some others have reported. This is many thousand dollars of savings even at today’s hardware prices.”
Tobias Lütke (Shopify)

And just like Phusion Passenger, Ruby Enterprise Edition is 100% open source.

Changes

Version 1.8.6-20090201 is a minor bugfix release. The changes are as follows:

  • Fixed a memory corruption bug in the readline library. If you were having problems with readline or irb, try this release.
  • Preserve file attributes when installing tcmalloc. Symlinks are now properly copied as symlinks.
  • For those who do not want to or can’t use the REE installer, there are now manual installation instructions available.

Download & upgrade

To install Ruby Enterprise Edition, please visit the download page. To upgrade from a previous version, simply install into the same prefix that you installed to last time. Please also refer to the documentation for upgrade instructions.

Hongli Lai Ninh Bui

Ruby Enterprise Edition 1.8.6-20090113 released, thanks to sponsors!

By Hongli Lai on January 13th, 2009

What is Ruby Enterprise Edition?

Ruby Enterprise Edition (REE) is a server-oriented distribution of the official Ruby interpreter, and includes various additional enhancements. REE’s main benefits are the ability to reduce Ruby on Rails applications’ memory usage by 33% on average, the ability to increase applications’ performance and the inclusion of various analysis and debugging features. The lower memory usage and increased performance are possible because REE includes – among other enhancements – a copy-on-write friendly garbage collector, as well as an improved memory allocator. REE has been out for several months now and is already used by many high-profile websites and organizations, such as New York Times, Shopify and 37signals.

“We switched to enterprise ruby to get the full benefit of the [copy-on-write] memory characteristics and we can absolutely confirm the memory savings of 30% some others have reported. This is many thousand dollars of savings even at today’s hardware prices.”
Tobias Lütke (Shopify)

And just like Phusion Passenger, Ruby Enterprise Edition is 100% open source.

Sponsorship results

We are pleased to announce REE version 1.8.6-20090113 to the world. This version is sponsored by the following people and organizations:

We were pleasantly surprised with the speed at which the second sponsorship campaign’s goal was reached. Thank you sponsors!

Changes

The sponsored improvements are:

  • Tcmalloc support for 64-bit operating systems.
    
REE’s copy-on-write optimizations work on 64-bit operating systems. But the improved memory allocator that REE includes, tcmalloc, was disabled on 64-bit platforms for various reasons. It would be more efficient if tcmalloc is enabled on 64-bit platforms because it would allow one to save more memory and to gain more performance. In this release, tcmalloc now properly integrates into Ruby on 64-bit platform.
  • Ported and incorporated the RubyProf GC patches.
    
These patches add the ability to measure the number of objects in Ruby and to measure the amount of allocated memory, which is very useful in various debugging scenarios. RubyProf automatically uses this functionality for GC profiling if the Ruby interpreter is properly patched.

  • Better documentation.

    A lot of cool new features, e.g. caller_for_all_threads and the RailsBench patches, had been added to REE lately. These features aren’t very well documented, and the existing documentation was scattered all over the Internet. We’ve written a unified manual which teaches developers how to effectively use these new REE features to debug applications.

We’ve also added a number of improvements which are not sponsored:

Fixed –no-tcmalloc on OS X
Running the installer with –no-tcmalloc didn’t work on OS X. This has been fixed.
Fixed more bugs in GNU readline integration on OS X
Requiring “irb/completion” causes REE to crash when running on OS X. This has been fixed. Also, GNU readline has been added as dependency, so the installer will now check for it.
Pass ‘-r’ to ‘gem install’ when installing gems
The REE installer will now pass ‘-r’ when installing gems. This fixes gem installation for people who have specified ‘-l’ in their ~/.gemrc.
Fixed a crash when using REE to install REE
This is caused by the fact that we overwrote tcmalloc without unlinking it first. This has been fixed.
Fixed Debian package
The Debian package for the previous release contains a mysterious folder called ‘/home/hongli’. This bug has been fixed.

Download & upgrade

To install Ruby Enterprise Edition, please visit the download page. To upgrade from a previous version, simply install into the same prefix that you installed to last time. Please also refer to the documentation for upgrade instructions.

Ruby Enterprise Edition second sponsorship campaign

By Hongli Lai on December 30th, 2008

What is Ruby Enterprise Edition?

Ruby Enterprise Edition (REE) is a server-oriented distribution of the official Ruby interpreter, and includes various additional enhancements. REE’s main benefits are the ability to reduce Ruby on Rails applications’ memory usage by 33% on average, the ability to increase applications’ performance and the inclusion of various analysis and debugging features. The lower memory usage and increased performance are possible because REE includes – among other enhancements – a copy-on-write friendly garbage collector, as well as an improved memory allocator. REE has been out for several months now and is already used by many high-profile websites and organizations, such as New York Times, Shopify and 37signals.

“We switched to enterprise ruby to get the full benefit of the [copy-on-write] memory characteristics and we can absolutely confirm the memory savings of 30% some others have reported. This is many thousand dollars of savings even at today’s hardware prices.”
Tobias Lütke (Shopify)

And just like Phusion Passenger, Ruby Enterprise Edition is 100% open source.

Announcing the second sponsorship campaign

The last REE sponsorship campaign was a huge success. Thanks to the last campaign REE has gained 64-bit OS support, MacOS X support and Solaris support. It has incorporated the RailsBench GC enhancements, which allows one to further improve server performance by tweaking the garbage collector settings.

We hereby announce a second sponsorship campaign. Unlike the last campaign, this one is public and everyone can participate.
This campaign will cover the following work:

  • Tcmalloc support for 64-bit operating systems.
    
REE’s copy-on-write optimizations work on 64-bit operating systems. But the improved memory allocator that REE includes, tcmalloc, is disabled on 64-bit platforms for various reasons. It would be more efficient if tcmalloc is enabled on 64-bit platforms because it would allow one to save more memory and to gain more performance. We’ll perform the necessary work to properly integrate tcmalloc in 64-bit operating systems.
  • Porting and incorporating the RubyProf GC patches.
    
These patches add the ability to measure the number of objects in Ruby and to measure the amount of allocated memory, which is very useful in various debugging scenarios. RubyProf automatically uses this functionality for GC profiling if the Ruby interpreter is properly patched. The existing patches aren’t fully compatible with REE at this moment. We can port these patches and make sure that it works properly with the existing REE patches.

  • Better documentation.

    A lot of cool new features, e.g. caller_for_all_threads and the RailsBench patches, have been added to REE lately. But at this time, these features aren’t very well documented, and the existing documentation is scattered all over the Internet. We can write a unified manual which teaches developers how to effectively use these new REE features to debug applications.

The goal of this campaign is 2000 USD. Once the campaign goal has been reached, we’ll release the work as soon as it has been finished. Highlights:

  • All sponsors will be given credit on the related REE release announcement on our blog. If the sponsor is an organization then we’ll link to the website, if available.
  • The money that we receive through this campaign shall be treated like donations.
  • An invoice is available if both of the following conditions apply:
    1. You are an organization based in the European Union.
    2. You’ve sent 200 USD or more.
  • If we receive more money than 2000 USD, then the surplus will be used for the next REE sponsorship campaign.

To sponsor this campaign, please click on the following button:
Click here to lend your support to: Ruby Enterprise Edition second sponsorship campaign and make a donation at www.pledgie.com !

Thank you, and we wish you a happy 2009!

Ruby Enterprise Edition 1.8.6-20081215 released

By Hongli Lai on December 15th, 2008

Ruby Enterprise Edition 1.8.6-20081215 has been released. This version includes one bug fix:

Fixed compilation problems on newer versions of GCC
People using Ubuntu 8.10 and other recent distributions with a recent version of GCC experienced compilation problems. This has been fixed.

Download & upgrade

To install Ruby Enterprise Edition, please visit the download page. To upgrade from a previous version, simply install into the same prefix that you installed to last time.

Re: EngineYard’s recent post about Phusion Passenger

By Ninh Bui on December 6th, 2008

At Phusion, we’ve received some comments from Engine Yard customers who have mentioned that upon requesting support for Passenger, they were advised to stick with an Nginx + Mongrel setup instead. Even though Passenger is our flagship product, I also have the utmost respect for both Mongrel and Nginx, and believe that people should choose the solution they deem most suitable and pragmatic for the job. In light of this, I believe Passenger and Apache are just as viable a solution for “the deployment problem” as the aforementioned solutions. Unfortunately, after inquiring a bit further, I was unable to get a clear answer as to why they were advised by Engine Yard to not use Passenger specifically.

After reading some responses on Ezra’s talk on Rails deployment, and in particular, after reading this summary by an attendee of this talk, the impression seemed to be made that Passenger was only, if not more suitable, for small VPS and/or shared hosting environments. Unfortunately, I was unable to attend this talk myself but luckily, Ezra has made his slides publicly available on his blog.

Here, slide 13 states “Passenger(with caveats)” and “State of art now: Passenger for shared hosting/small VPS”. Clearly, we’re unable to infer what is being said here without the proper narrative/annotations which unfortunately isn’t available. This leaves room for interpretation and the slides on their own seem to suggest that Passenger “has caveats” and is the best solution for shared hosting/small VPS. Even though it seems to do a great job in these fields, it’s certainly not the only goal we had in mind when we were designing and engineering Passenger.

Taking this into consideration, I felt inclined to further investigate and asked Ezra for some elaboration in the comments section of the aforementioned blogs. Here it soon became apparent that Ezra seemed to have problems with the memory consumption of Apache and Ruby Enterprise Edition(REE) not giving them memory savings on 64bit platforms but segfaulting instead.

As I’ve pointed out earlier in the comments section of Ezra’s blog, I believe it’s one thing (and very unfortunate) that saying one solution isn’t working out for Engine Yard, but it’s an entirely different matter to give the impression that is therefore more suitable for VPS/small hosting. Especially if no specifics are or have ever been given about this potential problem in order for people like us to try to reproduce it. After asking for these specifics, Ezra commented that he would contact us on this, but Ezra is probably a super busy man so we unfortunately didn’t receive anything on this as of yet. The just recently released Ruby Enterprise Edition however, contains fixes that should increase the support for 64bit and we hope that they will solve any problems people might have with this on their 64bit platform.

Update:
It seems Ezra sent us an email at around the same time this reply was posted which contents now seems to indicate a working REE setup on their 64 bit platform! :-) I’d still be interested in learning more about their test suite though which would allow us verify a working setup through reproduction, and I’m sure the community would benefit from having this kind of knowledge as well.

Many thanks to the following people and organizations for making this possible through sponsorship (list sorted in alphabetical order):

After releasing both Passenger 2.0.5 and Ruby Enterprise Edition, Tom Mornini from Engine Yard elaborated a bit more on the reasons why Engine Yard is currently favoring Nginx + Mongrel over Passenger + Apache. Seeing as some reasons are given with regards to Passenger and Apache, I’d like to go over these to try to get the entire story across for you to decide whether or not it is suitable for you.

First off, Tom writes:

“If you’re running multiple Rails applications, and are using Passenger’s ability to serve more applications than applications processes, you need to be aware of the performance of requests requiring an application process switch from one application to another. First requests are always slow, as a *lot* of code needs to be heated up, etc.”

Here, I believe the very first thing to note is the first word Tom uses in this paragraph, being “if”. “If” you are running multiple Rails applications and are using Passenger’s ability to serve more applications than application processes, then yes, you need to be aware of the possibility of the performance of requests requiring an application switch from one application to another. The reason why I’ve emphasized possibility here is that you need to have more concurrent requests in progress than application processes in the first place in order to be able to get into such a situation. Having said that, one could just as easily increase the allowed application instances Passenger is allowed to spawn to the number of applications we have and increase the PassengerPoolIdleTime to a sufficiently large number so that they will virtually live as long as you’ll ever need. In git master, we’ve made this solution a bit more elegant by providing a sugar that allows you to assign a negative value to PassengerPoolIdleTime, which will result in it “living infinitely long” and you can expect this to be in 2.0.6. Doing something like this will essentially give you the same behavior as having and keeping multiple mongrel instances alive behind a proxy balancer. The key thing to note here however, is that we actually allow you to choose for an alternative setup as well to accommodate your needs even better. Just as there are situations in which you want the behavior Tom is describing, there are situations where it is perhaps deemed more suitable to have less application processes than actual applications (e.g. where memory is limited). The important thing to remember here however, is that Passenger allows you to do both (very easily). Doing the aforementioned with Passenger requires you to just modify two numeric values in the Apache configuration (PassengerPoolIdleTime and PassengerMaxPoolSize) and doesn’t involve manual port management for example which in general, is necessary for proxy-load-balanced-mongrel setups. Using Passenger to establish the same setup as proxy-load-balanced-mongrel setups involves significantly less steps, making it arguably less tedious and less error prone to maintain. Unfortunately, this part isn’t elaborated on in Tom’s post, which could result in people being left only half informed.

Also, Tom has made mention of Passenger possibly needing to load a “lot” of code. Even though Tom acknowledges that Ruby Enterprise Edition *does* offer the additional advantage of memory savings, there doesn’t seem to be an explicit mention of the fact that Ruby Enterprise Edition negates “this need to load a lot of code” dramatically/entirely by leveraging a technique called Copy-on-Write which is available on a myriad of *nix variants. Copy-on-Write works on an operating systems level so if you already have a running Rails process, by the time you need to spawn a new one, the operating system is able to infer that most –if not all– memory can be pooled and doesn’t need to be replicated. This in particular is the case for identical applications, where not only the Rails framework will be shared among processes but also the application code.

Moving on, Tom writes:

“The issues I’m discussing are generally acceptable in a situation where you have many low traffic applications, and you need to run those applications in a very limited environment. At Engine Yard, this is a very rare need for our customers, so this makes us less anxious to switch to something new -vs- something that is proven and works well.”

Even though just shy of 8 months in production status, a growing number of very large sites (see here and here) are using REE and Passenger to successfully serve millions upon millions of request per day respectively. I’m not sure what one would need to do to get it to a point of being considered “proven and working well”, but what I do however know is that sites by MTV, Yammer, Geni, Shopify and 37signals are powered by Passenger and seem to have no problems dealing with high-volume requests.

Moving on, Tom writes:

“With the additional of Ruby Enterprise Edition, however, it *does* offer the additional advantage of memory savings. Some of those advantages are lost by having to run Apache, which as commonly delivered, is considerably larger and less efficient than nginx. Of course, you can reduce these disadvantages by cuting down a custom build and tweaking the included modules, but once you’re headed down that road, the simplicity advantage has left the building. :-)

Even though we’ve also inferred that an “out-of-the-box” Apache installation incurs a larger overhead than an “out-of-the-box” Nginx, it begs the question if this is really relevant in this article. After all, I was under the impression that Tom was elaborating about why Engine Yard isn’t using Passenger + Apache, where he also mentions that one can configure Apache to get comparable results to Nginx, effectively giving the answer to Engine Yard’s own “problems” with Apache.

From our experience, configuring an Apache setup to “perform on par with Nginx” isn’t trivial, but it’s very doable. Also note that this initial time one spends on setting up such an Apache installation is being rewarded by not having to maintain a relatively more difficult setup with nginx+mongrel. Here, you need to ask yourself how much time you spend on doing an Apache setup as opposed to maintaining the actual installation, i.e. how many times you update Apache as opposed to maintaining and updating Passenger. In general, from our experience, the former doesn’t take as nearly as much time as the latter. To get a sense of what I’m trying to get at, please take a look at the Apache site where you can see that the previous and most current version were released about 9 months apart from each other by the time of this writing. If we also take into account that in general, your old Apache configuration files will probably still work after doing an Apache upgrade, then I’m not sure if this really is such a big problem as it is made out to be. Especially with the solution we’re currently working on, which I hope to be able to elaborate a bit more about soon.

One thing is for sure however, heavily visited Passenger powered sites like Shopify which processes millions upon millions of requests per day
certainly don’t seem to have a problem with neither memory or performance and benefit greatly from this approach.

In particular, you might find the following quote from Tobias Lütke of Shopify fame
to be of particular interest:

“We switched to enterprise ruby to get the full benefit of the [copy-on-write] memory characteristics and we can absolutely confirm the memory savings of 30% some others have reported. This is many thousand dollars of savings even at today’s hardware prices.”

Moving on, Tom writes:

“Second, our customers choose Engine Yard for experience and expertise in hosting Rails applications. At this moment, we have no experience or expertise in Passenger™.
That is a fact.”

Well fortunately, Phusion offers commercial support for Passenger so this doesn’t necessarily have to be a problem. ;-) More interestingly however, is that even though Engine Yard claims to not have experience or expertise in Passenger, they seem to be perfectly capable of making some strong statements about it anyway as found on Ezra’s slides and Tom’s blog post. This also, is a fact.

In closing, somewhere in the middle of the article, Tom writes:

“The reason that I felt compelled to respond to Pratik’s Twitter post is that it entirely ignores a few issues that prevent Engine Yard, and no doubt other companies from immediately supporting Passenger™ and/or Ruby Enterprise Edition.”

In a similar fashion, I felt inclined to respond to Tom’s article seeing as it completely seemed to ignore a few (easy) solutions as well.

The morale of the story: feel encouraged to try out different solutions to find out which one suits you best, regardless of its current life-span, because that’s the only way of helping a product mature. In any case, please remain critical of information you receive, and yes, that even means this blog post. Seeing is believing right? Whatever the case may be, stay tuned for more exciting news from Phusion. :-)