Is Phusion Passenger (mod_rails) good for single app servers

There is a lot of hype over mod_rails, but from my understanding it is
more geared for servers with a number of apps on it. The reason it
seems that way is how it frees up the memory if an app is stagnant for
an extended period. The freeing up of the memory may not be an issue if
the application gets a continuous traffic flow.

I have a site that I will be putting up in a couple days and am
wondering if mod_rails is the way to go, or if I should stick with

Thanks for the input.

Don't stick with mongrel. Go with mod_rails :slight_smile:

You can easily configure idle timeout value to be very high so that
the process never gets killed. Check their docs.

Pratik wrote:

Don't stick with mongrel. Go with mod_rails :slight_smile:

Yes, please be an early adopter. It always pays off. Just ask the first
couple of iPhone owners. :wink:

- --
Phillip Gawlowski

Use recursive procedures for recursively-defined data structures.
~ - The Elements of Programming Style (Kernighan & Plaugher)

FUD FTW. Take that, Pratik!

I tried mod_rails yesterday and today to evaluate it. I have been
running a couple rails sites on thin (3 instances) + nginx for a while.
mod_rails worked as expected and I didn't run into any problems.

The platform was ubuntu, I installed the gem and apache module, followed
the steps laid out by the installer. After restarting apache, everything
worked as expected.

I did some basic benchmarking and it appears to be about the same as
mongrel speed wise for me. Memory usage was also comparable with mongrel
each taking about the same memory.

It was nice uninstalling mongrel, mongrel cluster and/or thin and
removing all that deploy code from capistrano. now it is as simple as
update_code through capistrano and touch the restart.txt file

I recommend the switch personally.

Nathan Esquenazi wrote:

It was nice uninstalling mongrel, mongrel cluster and/or thin and
removing all that deploy code from capistrano. now it is as simple as
update_code through capistrano and touch the restart.txt file

I recommend the switch personally.

I do have it installed so now that I think about it I might as well give
it a go during the initial live run through.

Do you happen to have the deployment recipe handy?

Nathan (and any others):

I'm curious about really heavy loads. If one were to have a very
beefy, dedicated server (say multi-processor, multi-core with 4+ GB
memory) and one were expecting a very intensive Rails app... i.e. LOTS
of requests as well as large uploads/downloads and such, would
mod_rails handle it better?

I've got just such a requirement and I'm starting to gather intel on
the best options for deployment. I'd be able to put pretty much
anything on the box, so I'm not constrained in any way. I'd love to
see some heavy benchmarking between the "players" in rails app space.

I suppose I'll just give it a try myself, but I'd love to hear any
stories (success or otherwise) from those who've already been down
this path.


Probably not worth posting the deployment recipe since it is so
minimalistic. Essentially, we just scrapped the entire deploy namespace
we used to have and instead just have the start and stop recipes to
start and stop apache:

sudo "/etc/init.d/apache2 [...]"

and then the restart for deploy is:

run "touch #{current_path}/tmp/restart.txt"

Super easy to manage. I am loving it so far. As to the question of a
dedicated server and mod_rails, I am no expert but one advantage to
mod_rails is that the number of instances isn't fixed.

This means that with thin or mongrel, under heavy load or light load,
there will always be X instances running (3 or 4 usually). These
instances will always be running on the server and are manually

With mod_rails instances are created and destroyed on the fly
dynamically by the apache module. So this means that under heavy load,
more instances can be spawned into the pool and then they will fall away
as the load lightens.

That is an advantage in itself although feel free to point out my
misunderstanding If I got that wrong.

So what is capistrano doing for you now? Do you still get the notice
that the site is down for redeployment? Otherwise, how do you keep
migrations and code in sync?

Sorry for all the questions, just about to start using mod_rails but
not sure how it's going to play with capistrano

Capistrano does a number of things now for me:

Checks out the code from my repository
Archives my log file, and starts a new one
Clears the fragment and action caches
Restarts up backgroundrb to reflect code changes
Copies over necessary production files
Restarts the mod_rails application
Put up the maintenance site when I am making changes

among other tasks.

I still use capistrano to do all the same stuff it used to do (i.e any
server tasks I need to have happen) but I just don't need the "deploy"
namespace quite so much since mod_rails handles the actual server