Choosing The Best Deployment
A major motivation for writing Mongrel was to make it easy to deploy Ruby web applications within existing infrastructures and organizations. Most of the companies I tried to pitch Ruby on Rails to loved how fast and easy it was to develop, but ran screaming when I talked about FastCGI.
Mongrel fixes this by just being a plain HTTP server that is still very fast. It’s easy to deploy, cluster, manage, and scale with existing web application technologies. You can put it behind hardware load balancers, load balancing web servers, proxy servers, or just by itself.
With this flexibility comes a bit of confusion though. Many people start off wondering how best to deploy Mongrel and then get confused with all the different options available. This document hopefully will help you pick the right deployment for your needs. They are listed in order from smallest/simpler to largest/complex.
Deployment Considerations
There are a few initial things you’ll have to consider when picking a deployment:
- Concurrency—Rails is not thread safe, so if you have giant actions that take minutes to complete then take that into consideration.
- Requests/Second—Notice I didn’t say “users”? Users is a useless measurement of your performance requirements. You want to know how many requests per second you have to process.
- Content Size—What’s the size of the content you’re serving. Mongrel is pretty decent at static files, but it can’t beat a good solid web server for pushing out big files.
- Dynamic vs. Static—Mongrel can serve static content for small sites, and of course do dynamic Ruby generated content, but you’ll want to figure out what the mix is so you can scale it later.
- Available Resources—You can’t cram a truck into a breadbox. Make sure you have the right deployment for your resources such as memory, disk, CPU, etc.
Scalability Means Expansion Not Speed
I’m not sure where the term “scalability” changed from it’s original meaning, but you should throw out any notion of scalability meaning “high performance”. Scalability is about resources and how easy it is for you to expand those resources to meet new demand. This does not mean how many resources you can buy now for all the demand you’ll ever need. It means the ability to start small now, and then after you’re the next google you can expand.
Start Small
Everyone immediately jumps to the end of this document and starts with the absolute most complex and “scalable” deployment they can muster. What you really want to do is start with a very small and simple setup, and then expand as needed. This mitigates the risk that you’ll buy a bunch of stuff you really don’t need and keeps your initial pain and costs low.
Automate, Automate, Automate
You’re a damn programmer. You should be scripting the hell out of your deployment just like you do your testing. Automation reduces human error, makes your setups consistent, and many times can become a project itself just like Capistrano did.
The Recommendations
Once you’ve figured out all the basic things about your planned deployment you can start deciding which one you need at the moment, and what you might need in the future.
Wait. You did plan this deployment right? Ok, go back and actually plan it. This document is part of your planning, but you need to do your homework first to make a good decision.
Just Mongrel
Mongrel is actually pretty fast even when compared with web servers like Apache for serving static files. If your web application is just starting out, doesn’t need to coexist with things like PHP, and you don’t need SSL, then consider just running Mongrel by itself.
This is especially attractive if your application can utilize page caching. Mongrel is pretty quick for page cached sites and is able to handle quite a few concurrent connections.
Disadvantages
Mongrel will break down pretty quick if you have lots of people accessing Rails actions that are slow. It can still perform like a champ for most small needs, but if you start getting more serious then you need one of the next solutions.
Advantages
The easiest to manage, especially on win32. You just turn it on and go home. Maybe write a few /etc/init.d/ start-up scripts for your server if you’re running a POSIX system.
Behind TCP Balancers
You still don’t need SSL, but you do need to make a small cluster of Mongrel servers. If this is the case, then you can simply grab mongrel_cluster and either get Pen or Balance and do a simple cluster.
Advantages
This configuration is very easy to setup, gives you decent throughput and concurrency, and is easy to manage. Using mongrel_cluster gives you simple commands to control whole clusters of Mongrel servers and Pen or Balance simply accepts connections on one port and forwards them to one of the backend Mongrel ports.
Disadvantages
No SSL and you’re still relying on Mongrel to serve the files. A cluster of Mongrel servers
is no slouch though. I think many sites that don’t need SSL could run with this configuration
happily for years. A real good mix is to combine this with Rails’ asset server configuration
and a simple thttpd install to serve your static files.
Behind HTTP Balancers
If you need something like the above, but you also need SSL, then simply swap out Balance or Pen and use Pound instead. Pound is a very flexible HTTP balancer that also supports SSL. This gives you the same advantages of simple deployment but adds the security you need.
Advantages
The same as using a TCP balancer, except you now have SSL and you can do some more creative routing. A good example is if your site has to use a PHP web app for serving ads. You can have pound take requests for the advertising URIs and route them to the PHP application, and then transmit everything else to your Mongrels. It’s very flexible and much easier to install.
Disadvantages
You’re still relying on Mongrel to serve the files and passing that through Pound, but as mentioned before Mongrel is pretty quick with static files. Don’t underestimate it.
Behind Web Servers
If you have complex static file serving needs, need to host a PHP application at the same time,
or have complex authentication requirements, then you should use a regular web server. Mongrel
has good instructions for quite a few web servers and supports any server that has some form
of mod_proxy style support.
Each of the above documents describe how to get an initial configuration of Mongrel running behind that type of web server. You should also combine this with mongrel_cluster to manage the cluster of mongrel servers.
Advantages
Since you have a real web server handling the initial HTTP traffic you can easily do page caching and other magic to speed things up and avoid even talking to Mongrel. It also means you can put in authenticators, other web platforms, and extensions that your application might need. Many web servers are also installed and configured by default on most platforms and you just need to add the Mongrel specifics to get it going.
Disadvantages
This configuration can quickly descend into madness with complexity. Apache is notorious for having a horribly complex configuration file. Another disadvantage of real web servers is they almost always start of as web servers, and then proxy support is bolted on as an extra. Apache’s latest proxy support is really good as well as Litespeed’s, but Lighttpd’s proxy support is really bad (as of Mongrel 0.3.13).
Behind Hardware
If you are getting really really serious about your web application and you need to serve up lots of Mongrels then you should take a look at a hardware load balancer. They’re really expensive, but they’re usually worth it if you’re in the big leagues.
Advantages
Big big big loads and the ability to handle the SSL in hardware for many products. Also things like smart virus filtering, routing and other goodies, but you’ll pay for it.
Disadvantages
Expensive, Expensive, Expensive. Did I mention Expensive. One more time Expensive. They’re also a royal pain to setup properly, but then that’s why their Expensive.
