Passenger and other Ruby frameworks

Traffic for our Passenger (mod_rails) preview site has increased three fold ever since RailsEnvy and weblog.rubyonrails.org (thanks David) linked to us. We’ve received quite some emails from interested people. :) One of the questions that we receive most is:

“What about other Ruby frameworks, like Merb, Camping, etc?”

There is the following saying: jack of all trades, master of none. At the moment, our goal is to make Passenger a great deployment system for Ruby on Rails, one that is matched by none in terms of ease of use and low maintenance overhead.

But some people ask:

“What’s wrong with mod_ruby?”

  • For one, look at its website. Last release was from 2006. I’m not sure whether it’s still maintained anymore.
  • Nobody (or almost nobody) uses it in production. This fact alone says a lot.
  • The Rails wiki page for mod_ruby lists a pretty bad limitation:

    mod_ruby uses a shared interpreter per Apache process, which means that multiple Rails applications on the same Apache setup with mod_ruby would share the framework classes. This doesn’t work well with the Rails model of using class-level configuration attributes, so it’s considered unsafe to use mod_ruby and Rails with more than one application running per Apache setup, because different applications may start sharing the classes.

Granted, these are implementation problems and not conceptual problems, so they can be fixed. So some people ask:

“Why didn’t you just make a solid mod_ruby implementation?”

First, we must agree on the premise that Rails is a more popular framework than other Ruby frameworks. Wait, hold your flame thrower, this is not the reason. ;)

Next, try thinking from the point of view of a new Rails developer. He’s introduced to lala-land: Don’t-Repeat-Yourself, convention over configuration, stuff that’s supposed to Just Work(tm).

Then he deploys his Rails app and finds out that he has to setup a Mongrel cluster (1 command but usually with 3 or 4 options that he’ll have to look up), configure Apache to proxy to the cluster (about 5 or 6 lines that he’ll have to setup), configure init.d/daemon tools/monit/god/whatever so that his Mongrel cluster is started at system startup, etc.

Oh, and you need to repeat this for every single Rails app.

Ouch, is this the proper Rails experience? I don’t think so. This is Passenger’s philosophy: deployment should be in line with the Rails philosophy. In other words, it should be brain-dead simple. Just imagine the money that you’ll save on health care for your system administrator if he doesn’t have to worry about all that stuff anymore. ;)

Of course, the Rails philosophy doesn’t prevent deployment of other Ruby framework apps from being easy. So what’s holding us back? Well, here’s a few things that Passenger does but mod_ruby doesn’t:

  • Remember the screencast that we showed you? You can deploy a Rails app to a virtual host without any Ruby-specific or Rails-specific configuration! From this fact one can deduce that Passenger somehow automatically detects Rails applications (and yes, this autodetection can be disabled). Autodetection heuristics are framework-dependent. We’ll need different heuristics for each framework.
  • Passenger preloads framework code and application code in order to reduce startup time and to reduce memory usage. Preloading logic is framework-dependent.
  • Look at Troubleshooting obscure errors with mod_ruby. Notice the word “obscure errors” – errors should never be obscure or hard to track!

    We’ve seen many people failing to deploy Rails apps because of errors during application startup. Lighttpd’s FastCGI implementation redirects those errors to /dev/null. Not good, this fact bit me 2 years ago — when I was deploying my first Rails app — and made me wonder why the thing wouldn’t work. Mongrel prints errors either to stderr or to its log file. But people who are new to Rails deployment don’t know that they should be looking in the log files (or that there are log files in the first place). Plus, looking into the log file is yet-another-step. Wouldn’t it be great if you can see startup errors right in the browser?

    Passenger provides user-friendly error pages. If a Rails app failed to start, then Passenger will tell you what happened. A few possible error pages are:

    • Whether a (specific version of a) system-wide Rails framework failed to load. Passenger will even tell you the correct command to (re)install it.
    • Whether a vendor’ed Rails framework failed to load.
    • Whether the app failed to start because of a syntax error, or a missing gem. Passenger will suggest solutions.
    • Whether a database error occured during startup. Passenger will tell you to check your database.yml and to run ‘rake db:migrate’.

    Here are previews of typical error pages:
    error_page.jpg

    error_page_2.jpg

    As you can see, a lot of these error pages are framework-dependent.

As you may have noticed by now, we’ve put a lot of work into making sure that deployment is dead-easy. This is only possible if Passenger has knowledge about the frameworks themselves. We have a tight schedule and we only have 2 developers working on Passenger. Rails is more popular so it has more priority. We’re working around the clock to get this thing released.

Or we can get rid of the autodetection/preloading logic and just provide generic configuration options. But would you really want that? By no means should we force the system administrator to configure things. By default, stuff should Just Work(tm) out-of-the-box.

Hope this clears things up.

19 Comments »

  1. Charles said,

    March 27, 2008 @ 1:46 pm

    Wow! If you guys pull this off we will worship you. FastCGI is the spawn of the devil and mongrel is a pain in the buttocks. Seriously – mod_rails might make Rails twice as popular on its own.

  2. Kritikal » Blog Archive » Phusion Passenger (mod_rails): finally a good Apache module said,

    March 27, 2008 @ 2:54 pm

    […] Now, this is only for Rails and Hongli Lai talks about why this is in his blog post, Passenger and other Ruby Frameworks. […]

  3. Justin Mazzi said,

    March 27, 2008 @ 3:04 pm

    How does apache handle the rails applications as far as memory? Does it load the app into memory each time? How long do the processes last in memory?

  4. Keith said,

    March 27, 2008 @ 3:59 pm

    This is the most exciting news to come out about Rails since 2.0 was released. Thank you so much for your hard work on this and I’m really looking forward to testing it!

  5. Ninh Bui said,

    March 27, 2008 @ 6:37 pm

    @Charles:
    What do you mean by “if you guys pull it off”, we’ve already pulled it off! ;) We’re pretty much in the final stages of beta testing, and we’re really just polishing things right now.

    Also, we’re awaiting the test results from some of the largest Ruby on Rails webhosts, so that we can determine that Passenger is indeed capable of holding its own in a heavy-use production environment.

    @Justin:
    An excellent question. Our tight work schedule prohibits us from being able to elaborate on this for now, but this question will be answered in the developer documentation in great detail. For now, concerning memory and startup time, suffice it to say that it tries its best to be as efficient as possible. The amount of time a process lasts is configurable.

    @Keith:
    :D

  6. Neil Wilson said,

    March 27, 2008 @ 8:14 pm

    Does it create the database if it doesn’t exist? It’s always annoyed the devil out of me that migrations don’t try and create the database if it is missing. It’s not as if migrations doesn’t know what the thing is called.

    With this sort of deployment there definitely needs to be some way to automatically run ‘setup’ without necessarily having to trigger a rails action via a browser.

  7. Hongli said,

    March 27, 2008 @ 8:42 pm

    Does it create the database if it doesn’t exist? It’s always annoyed the devil out of me that migrations don’t try and create the database if it is missing. It’s not as if migrations doesn’t know what the thing is called.

    No. I’m not sure whether it is a safe thing to do because production servers can be accessed by multiple concurrent users. And it’s not easy to pull off without knowledge about the application. It is best that you implement such things in your application. For example, Typo does this.

  8. Alex said,

    March 27, 2008 @ 9:03 pm

    That’s Jack of all *trades*, not traits. That would be a horse of a different color…

  9. Nowne said,

    March 27, 2008 @ 11:05 pm

    Give me just one reason not to believe that mod_rails is complete vaporware…

    Come on, you just can’t have developed such a feature-complete and pseudo-perfect software secretly… Why would you have registered on RubyForge less than a week ago?

    Before trying to bake hoaxes, you guys should learn how Free Software works! You don’t just develop software on your own, then test it with a secret annonymous core member team, and then start teasing all around saying you are just polishing it up!

    So give us just something we can see by ourselves!

    When it’s too good to be true…

  10. Hongli said,

    March 27, 2008 @ 11:17 pm

    Give me just one reason not to believe that mod_rails is complete vaporware…

    Because we have the source?

    But hey, you don’t have to believe us. :) Ask Pratik “lifo” Naik and Jeremy “bitsweat” Kemper, both Rails core team members. They’ve helped us with beta testing.

    Come on, you just can’t have developed such a feature-complete and pseudo-perfect software secretly… Why would you have registered on RubyForge less than a week ago?

    Actually, we have. Development began somewhere in February, about the same time as this post. We registered less than a week ago because we’re close to a release and we need the RubyForge release system for gem distribution.

    If open source is what you’re worried about, then don’t worry. It is going to be 100% open source, by every meaning of the word. The only reason why it isn’t released yet is because we want 1.0 to be perfectly stable. We do not intent on releasing a half-assed, may-or-may-not-work half-documented piece of *****. You can expect a quality 1.0 release from us that’s stable, fast and 100% documented.

    Would you care for a little wager? If Passenger hasn’t been released by March 5th, then I’ll do whatever you want (you can make a screenshot of this comment to prove that I’ve said this!). If it has been released before that date, then I want you to hype it for a month. ;)

  11. Nowne said,

    March 27, 2008 @ 11:23 pm

    > Would you care for a little wager? If Passenger hasn’t been released by March 5th, then I’ll do whatever you want (you can make a
    > screenshot of this comment to prove that I’ve said this!). If it has been released before that date, then I want you to hype it for a month.

    Deal! March 5th is long gone ;-)

    Trust me, I really want to believe you guys! I spend hours every week struggling with fcgi crashes on shared hosts.

    You just can’t possibly expect your first release to be 100% bug-free! That’s simply not how it works!

  12. Ninh Bui said,

    March 27, 2008 @ 11:24 pm

    Beah Hongli, never should’ve let you talk me into making it 100% open source, Nowne would’ve made a fine exclusion clause in the license :( 99.9…% would’ve been just fine by me ;)

  13. Ninh Bui said,

    March 27, 2008 @ 11:27 pm

    @Nowne:
    Actually, he never mentioned any year so I guess the joke’s on you ;)

    But in all seriousness, please be a bit patience, we’re going the extra mile on this and people like you trying to rush us into releasing this isn’t really supportive. Like I said, not only do we have some of the largest Ruby on Rails web hosts working with us on this, but also the core rails team. If that isn’t credibility, then I don’t know what is. Again, please be patient.

  14. futzl said,

    March 27, 2008 @ 11:57 pm

    For me as a Rails developer, it would be nice to have detailed error messages instead of a plain “500 Something went wrong”. But when you call these error pages user-friendly, well, they’re not. They’re developer-friendly. Giving that kind of detailed information about what went wrong out to the public is also a security risk. All a user (of a website) wants to know is “This is broken, we might be working at it, try again later.”

  15. Hongli said,

    March 28, 2008 @ 12:13 am

    But when you call these error pages user-friendly, well, they’re not. They’re developer-friendly.

    Our users are developers. :) And system administrators.

    An option could be added to disable these messages. And these messages are only shown if something went wrong during startup, never if something went wrong after the Rails application has already started.

  16. Nowne said,

    March 28, 2008 @ 9:43 am

    Come on, that’s advertisers’ talking, not developers’

  17. simplificator » Blog Archive » Deploying Rails Applications with mod_rails said,

    March 28, 2008 @ 4:49 pm

    […] is pretty distracting! Can you create a new screencast without it ;-) ) And here is some more information on it. Anyone used it already ? Leave a comment or contact […]

  18. Neil Wilson said,

    March 28, 2008 @ 6:41 pm

    I think then a blog post on how to do automatic setup in Rails is probably in order.

  19. Eivind Uggedal said,

    May 13, 2008 @ 10:05 pm

    Have you heard about Rack? mod_rack?

RSS feed for comments on this post · TrackBack URI

Leave a Comment