Well, in what stage is your app at? How many users do you have to support? What's the app serving... lots of images or mostly text out of database? How much RAM is your app using with mongrels (check it with top)? What's your hardware setup like? If you're on slices, are they 32bit or 64bit and how much RAM do you have?
Passenger's great if you have a lot of RAM (say over 1gb). If you're on 256/512Mb slices, I'd stick with nginx+mongrel (or thins) since that combo will utilize less RAM and won't swap.
Finally, you should test and see for yourself how the app performs when you load it with httperf or something like that.
I would advise that unless you have a very good reason to not use it, you should go with Passenger. It's way simpler to set up, less moving parts, and you don't have to worry about monitoring mongrel, configuring proxies, and all that junk.
You can always change later if you discover it's not working for you, but until then go with the simplest solution that works, which is definitely Apache/Passenger.
And yes, I do use a staging server, or rather a staging directory which is hooked into a "beta" url. It's an invaluable final sanity check in the production environment. That is not hard - the tricky thing will be staging on something resembling the production database, you'll have to figure out some way of doing that.
Ironically, the staging environment is probably where you'll want to use mongrel, since you'll want to start the app with a different rails environment to point to your staging DB.
Nginx in front of a pack of Mongrels works fine for me. It is _VERY_ memory efficient, which is a nice property to have if you want to have a production Rails app running on a 256 MB VPS.
Staging server: I don't use one currently, as it is overkill for the complexity of the application I have, but will probably start using one during my next project.
Apache 2.2 and mod_proxy_balancer in front of a Mongrel cluster. If Passenger had been available when I set up the server, I'd probably have used that, but since it's working fine it's really not worth my time changing over.
I use Git to deploy my application, and then a Rake command to restart the cluster. In the past I used Capistrano, and then Vlad, but I found that they were overkill and just added unnecessary complexity to the deployment process.
apache 2.2 and mod_proxy_balancer in front of a Mongrel cluster for our main apps. we have started moving some of our ancilliary apps to Passenger to test the waters so to speak. seems to work great.
6 comments
[ 3.1 ms ] story [ 20.7 ms ] threadPassenger's great if you have a lot of RAM (say over 1gb). If you're on 256/512Mb slices, I'd stick with nginx+mongrel (or thins) since that combo will utilize less RAM and won't swap.
Finally, you should test and see for yourself how the app performs when you load it with httperf or something like that.
You can always change later if you discover it's not working for you, but until then go with the simplest solution that works, which is definitely Apache/Passenger.
And yes, I do use a staging server, or rather a staging directory which is hooked into a "beta" url. It's an invaluable final sanity check in the production environment. That is not hard - the tricky thing will be staging on something resembling the production database, you'll have to figure out some way of doing that.
Ironically, the staging environment is probably where you'll want to use mongrel, since you'll want to start the app with a different rails environment to point to your staging DB.
Staging server: I don't use one currently, as it is overkill for the complexity of the application I have, but will probably start using one during my next project.
I use Git to deploy my application, and then a Rake command to restart the cluster. In the past I used Capistrano, and then Vlad, but I found that they were overkill and just added unnecessary complexity to the deployment process.
And yes we have a staging setup.