Why Passenger Phusion Is a Better Hosting Solution Long Term

Since we started hosting Ruby on Rails applications in 2006, many of the pieces have changed. At each step, things became a bit easier and a bit faster. Here’s how things have changed.

Lighttpd => FastCGI on FreeBSD
We used this setup for probably 5-6 months. It crashed, we lost connections. It was a maintenance nightmare.

Nginx => Mongrel
This was a huge step up from FCGI. I want to thank Zed Shaw for his hard work on Mongrel as it’s kept us running for quite some time. It also allow us to move over to CentOS Linux (built from Red Hat Enterprise).

Nginx => Thin
This had a small increase over Mongrel, and since it used the Mongrel parser, it was an easy switch to make.

Apache2 => Thin
We never used this combination in production, but we did run it on test servers. Nginx is much faster at serving static files and our load tests showed it. Nginx and Thin were still the better choice.

Apache2 => Passenger Phusion (Mod_Rails)
This is our current setup. We didn’t choose to switch for speed. It is equivalent to Nginx and Thin. The reason we switched is for simplified setup and management.

We run all of our Rails and PHP applications inside CentOS virtual machines. With the first 4 versions, we had to run several different monitoring utilities (god, nagios, monit) to make sure things stayed up and the ram usage was kept in check.

With Passenger Phusion, it self monitors each Rails instance it spins up. It can and will restart those instances as needed to clean up memory. With larger applications you can go away from the round robin approach of choosing a ruby server to adaptive based on load (I don’t recommend this for small sites as there is some overhead to doing so).

In general this cut out a LOT of the day to day headache for us. With the old applications, sometimes the monitoring apps just couldn’t get things restarted. We have not had that issue with Passenger.

Also, we have been testing our apps with Ruby Enterprise Edition (also from the Passenger Phusion team), and will be using that in production. The copy on write memory management is fantastic. Garbage collection is much faster than traditional Ruby 1.8.x.

Here is some math to explain why it’s so great. Say we have 20 sites running 3 ruby servers each. Each of those 60 servers use 250MB of ram. That’s 15GB of ram. Ruby EE uses 30% less memory. that just saved us 5GB of ram. That’s a one time savings of $1,000, or I could use that extra memory to server 5 more virtual machines with the same equipment. That’s money in our pocket and faster site for our customer.

Even in a shared account at a place like Slicehost, Apache2, Passenger and Ruby EE are a great way to host your sites, keep them running and keep you under your ram limit.

Stopping running Mongrel and Thin for Rails apps. It just doesn’t make sense anymore.