RailsConf08: Passenger or mod_rails RIP

There was no lack of hubris on the stage today as the guys from Phusion talked about their new Apache extension Passenger. If Passenger lives up to its claims it seems that it could quickly become the de-facto standard for deploying Rails (and more) applications.

The 19 22-year-old duo was obviously ecstatic about sharing about what they created but I kept getting the feeling that they were surprised that the crowd didn’t give them a presidential-state-of-the-union-like standing-ovation every few minutes. (If passenger does what they claim maybe they deserve it but respect and appreciation often lose something when they are too eagerly expected.)

So what was it that they claimed? That passenger will not only make Rails deployment dead-simple (think PHP, upload and go) but also crank out better performance while using less memory. It’s a worthy goal and as Kent Beck said in our keynote, “Humility is not a prerequisite to ideas with impact”. I’d like to write up a bit about Passenger and the session they presented at RailsConf. You can download the Keynote slides here [zip] (I’m sure the PDF will appear somewhere soon. If you find it, please feel free to leave a URL in the comments).

Memory Usage and Clustering

Memory Usage

First lets talk about memory usage. When you’re using Mongrel each Mongrel process holds both a full copy of the Rails and application code in memory plus the private memory for the individual process. In this model of N Mongrel processes you have N copies of the application code. With Passenger, each process shares one copy of your Rails/application code. Each process still gets its own chunk of private memory but the shared code greatly reduces the overall memory usage.

The Phusion guys also patched Ruby (and they’ve horribly named it “Ruby Enterprise Edition”). This version has modified garbage collection and causes Ruby to use significantly less memory. They achieve this by doing copy-on-write for memory management. This hasn’t been released so no word yet on how well it works or how stable it is.

Clustering

Another nice feature is that with clustering they use “fair load balancing”. The idea is that you keep track of how many jobs each process in the cluster has and you give the next job to the process with the least amount of work to do.

Competitor Comparison

They compared Passenger’s performance (as an Apache extension) to many competing products (including Nginx and Mongrel) and claimed that it used significantly less memory and was much faster. I won’t repeat all the statistics, you can check out the slides.

mod_rails, RIP

Although they had greatly simplified deployment for Rails they didn’t stop there. Passenger now supports Rack. I see this as probably the coolest thing about Passenger. Now any custom server that you write using Rack can be basically “dropped” into Apache and is effortlessly handled by Passenger. This also means that rails alternatives like Merb and Camping work out of the box. But there is more…

They also added in support for Python’s Django. It was almost comical: when they announced this the crowd nearly boo’ed them. I think it was a bit unfair, but I guess they should have expected it at a Rails conference. Either way, you have to give them props for taking the initiative and pushing the software to its boundaries.

Because Passenger supports frameworks other than Rails they decided to drop the name mod_rails and call it Phusion Passenger. They mentioned that their focus is still going to be developing and perfecting Rails. Passenger will simply not be exclusive to Rails.

Case Studies

Passenger is already being used in production at Dreamhost. It is also being used soocial and ilike.

The Q&A

By the Q&A the crowd was full of skeptics; what they promised seemed too good to be true. However, one gentleman from the crowd sensed this, stood up, and said that he works with a developer/deployer Tom that has been working with production Rails deployment for 4 years. Tom apparently knows the in’s and out’s of Mongrel, Monit, Capistrano, etc. They found out about Passenger two or three weeks ago and he deployed all of their existing applications to Passenger in a single day. His comment was:

Everything I learned [about Rails deployment] over the last few years is moot now, and that is a good thing.Tom the deployer

He said that “[Passenger] is incredibly awesome when it comes to rails deployment.”

A skeptic stood and rightly asked: “Why wasn’t this done five years ago? What was the technological hurdle?” The team answered that they believed the problem was largely social. Developers that had written Rails applications wanted to deploy them as quick as possible. They researched, learned about Capistano, Nginx, and Mongrel etc., and made it work. The Phusion team said that the people that were smart enough to tackle this problem were complacent and choose to deploy applications in this (painful) way.

There is nothing technically preventing [ease of rails deployment]. We’ve shown it’s possible. Why it hasn’t been done is a social or political problem. There is no technical things stopping you. -Hongli Lai (Phusion)

Summary

Time will tell us if Apache/Passenger will live up to the hype and become the new standard. I, for one, am hoping that it really does take hold. If Rails deployment becomes as common and easy as PHP deployment we can spend time solving more interesting problems and that will be a good thing.

Share:
  • del.icio.us
  • Reddit
  • Technorati
  • Twitter
  • Facebook
  • Google Bookmarks
  • HackerNews
  • PDF
  • RSS
This entry was posted in programming, rails, ruby and tagged . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.
  • http://ninh.nl Ninh

    Hey dude (or dudette ;-) )

    I believe there has been a lot of misunderstanding here. First off, Hongli Lai and I are 22 years old instead of 19 ;-) Just thought I’d point that out to you. Also, the last quote was from Hongli Lai. But most importantly, the session was about entertaining the folks, and yes, the asking for ‘applause’ was just a joke :-) Luckily, it was well received, although unfortunately, as it seems to appear, not everybody got into the joke: a presentation that involves Yoda, declarations of love toward Leah Culver etc… seemed not to be clear enough signs in retrospect for all people.

    Lastly, the pdf’s are stale… (but you’ve probably concluded this for yourself as well, seeing as the layout as well as its content is totally different from what we’ve shown). We’ll try to put the real deal up online as soon as possible (we’ve got limited internet access right now, actually, we’re typing this from an apple store right now)

    Nonetheless, thanks for the support!

    Cheers,
    Hongli Lai
    Tinco Andringa
    Ninh Bui

  • Matt Pulver

    Great article! Would be interested to hear Engine Yard’s comments on Passenger, and Ezra Zygmuntowicz’s in particular (the author of “Deploying Rails Applications.”)

  • http://slightlycoded.com Taelor

    @Matt

    I have heard an interview with Ezra somewhere (maybe ruby inside?) and they asked him about Passenger. He was kinda “eh” about it saying it would be good for medium sized apps, but what really got him stoked (and me stoked) is the introduction of Rack and using that to run Merb.

    Now, if I can just get Dreamhost + Merb + Passenger to work…

    And to the guys of Phusion, just keep on keeping on…

  • Nate Murray

    @Taelor

    Right, as I understanding Ezra is a bit “meh” about the future of Rails in general. If I had to take a guess I’d say that he does it to pay the bills, but the fact of the matter is Engine Yard is the primary financial backing for Merb (e.g. Yehuda Katz is on staff there: http://engineyard.com/about/whoweare). So they have a good amount vested in seeing Rails competitors (Merb) have more success.

  • http://www.mydogspace.com Robert

    I moved over to passenger/modrails (from mongrel) and ruby enterprise about 2 weeks ago. And so far – my experience is that it is a lot better on memory and deployment.

    - one web site that was on ec2 med running on mongrel, I moved over to the smaller ins using mod rails and it still consumed less memory
    - it is easier to tune (all via apache conf)
    - easier to debug (it has some minor tools for mem usage etc)
    - the build in load balancing means if an instance is in trouble, it will eventually get released back to the pool. For mongrel – it just hanged and locked the resource
    - the best (for me), I can kiil a ruby instance without affecting the whole site
    - the added bonus – it fixed the recent ruby updates

    I’m sold!!