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 mongrel.

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 Twitter: twitter.com/cynicalryan

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.

-Danimal

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 maintained.

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 administration.