diff options
Diffstat (limited to 'site/src/docs/choosing_deployment.page')
| -rw-r--r-- | site/src/docs/choosing_deployment.page | 178 |
1 files changed, 178 insertions, 0 deletions
diff --git a/site/src/docs/choosing_deployment.page b/site/src/docs/choosing_deployment.page new file mode 100644 index 0000000..7a91e25 --- /dev/null +++ b/site/src/docs/choosing_deployment.page @@ -0,0 +1,178 @@ +--- +title: Choosing Deployment +inMenu: false +directoryName: Choosing Deployment +--- + +h1. 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":http://www.rubyonrails.org/ 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. + +h2. 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. + +h3. 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. + +h3. 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. + +h3. 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":http://manuals.rubyonrails.com/read/book/17 +did. + +h1. 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. + +h2. Just Mongrel + +Mongrel is actually pretty fast even when compared with web servers like "Apache":http://httpd.apache.org/ +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. + +h3. 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. + +h3. 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. + + +h2. 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":/docs/mongrel_cluster.html and either +get "Pen":http://siag.nu/pen/ or "Balance":http://www.inlab.de/balance.html and do a simple +cluster. + +h3. 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. + +h3. 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":http://www.acme.com/software/thttpd/ install to serve your static files. + +h2. 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":/docs/pound.html 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. + +h3. 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. + +h3. 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. + +h2. 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. + +* "Apache":/docs/apache.html +* "Litespeed":/docs/litespeed.html +* "Lighttpd":/docs/lighttpd.html *not recommended* + +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":/docs/mongrel_cluster.html +to manage the cluster of mongrel servers. + +h3. 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. + +h3. 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). + + +h2. 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. + +h3. 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. + +h3. 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. + |