Hi there,
A newbie question:
Why a separate server - mongrel or webrick to be used when apache with
a mod_ruby (not sure if this exists) could have done the job.
thanks
-Prasad
First off I’m guessing you’re coming from PHP and the whole mod_php
thing. That’s cool, nothing at all wrong with that. In fact if you
want a similar deployment scheme with Ruby on Rails you can get the
low-down on it here:
However, this is not the only way to deploy a Rails application. In
fact many people aren’t even using Apache as the front-end web server,
so a mod_rails doesn’t even make sense in those cases. In fact for
smallish in-house kind of stuff you could use straight up Mongrel,
Thin, or whatever without having an Apache front-end at all.
I found this blog post, it seems a little out-of-date given some of
the newer options like Thin and Passenger (mod_rails), but it looks
like a pretty good introduction to the world of options available for
hosting Rails applications:
http://blog.codahale.com/2006/06/19/time-for-a-grown-up-server-rails-mongrel-apache-capistrano-and-you/
Hope that helps.
Some people tried to use plain mod_ruby years ago, but it didn’t perform
well.
Webrick might be OK for home testing, not for production. It’s not being
developed any more.
The good thing about mongrel is that it runs as a number of independent
processes, which makes it scalable. It uses Apache or another HTTP
server
(lighttpd, nginx) as a load balancer. I’ve only tried it locally but
from
what I hear, it is preferable to any Apache-only solution. Thin is based
on
mongrel and said to be even faster (
).
Of course most hosts don’t offer these yet, so you’re stuck with Apache
mods.
The classical way to serve Rails over Apache is to use fastcgi. (cgi is
possible, but only in theory because it is extremely slow. If ever, use
it
in development mode only.) The problem with fastcgi is that it is
unstable
and causes a lot of 500s (Internal Server Error). Just google for
“incomplete headers (0 bytes) received” and you know what I mean. It
also
needs a custom .htaccess and doesn’t scale well. mod_rails (Passenger)
promises to be the solution. Hopefully hosting companies will adopt it
soon.
I’m with Dreamhost where many Rails sites are hosted. fastcgi is a real
pain there because they have a daemon that loves to kill your running
fastcgi processes. They refuse to offer mongrel to their shared-hosting
customers.
Instead, Dreamhost went off on a tangent (
http://blog.dreamhost.com/2008/01/07/how-ruby-on-rails-could-be-much-better/
) against the Rails developers, to which DHH instead of admitting that
Rails should have taken care of a usable Apache interface earlier,
replied
( http://www.loudthinking.com/posts/21-the-deal-with-shared-hosts ) in
the
same inane fashion.
That was in January. Things have changed. Now Dreamhost seems to be
testing
mod_rails internally, I can’t await it!
Robert W. schrieb: