There are two basic approaches to increasing the capacity of traffic that your site can handle, scaling up and scaling out. Scaling up means increasing the resources of a single web server machine, obviously a machine with faster processors or multiple processors and maxed out on RAM is going to handle more traffic and provide better performance than a less powerful machine, so scaling up is usually the first step needed to increase capacity for handling web requests. A single powerful web server can really handle a great deal of traffic especially if it is only running a single web site. Even running the database on the same machine this kind of server should meet the needs of the vast majority of web sites since the vast majority of web sites don't really get that much traffic.
The first bottleneck in capacity is usually the database, so the next step is to move the database onto its own machine or even better a cluster of machines which can provide redundancy and allow maintenance of individual machines while the other machines handle the load, so there is no single point of failure for the database. So in this example we are scaling out the database server with additional machines in a cluster, whereas making the individual machines more powerful is a scaling up strategy.
Then of course we don't want a single point of failure for the web server either so the next step is to have a failover cluster for the web server so that if one machine goes down or needs maintenance a second machine can be brought online quickly to take over the load while the other machine is being worked on or updated. In this case you would want to store the site files or at least the writable portion of the file system on a network share, ideally a raid environment so the disk drive is not a single point of failure either. This requires using some special shared configuration.
So the above kind of architecture is very robust, it can handle a great deal of traffic and should be very reliable since there is no single point of failure and historically mojoPortal can work well with this kind of infrastructure.
Scaling out is a strategy for increasing capacity that involves distributing the load over multiple machines. In general we can speak of scale out strategies as web farms though there can be a wide variety of ways to implement a web farm, they all generally involve using multiple machines and distributing the load across them. This is a much more complex solution that brings a range of problems to solve in order to make it work well. We will discuss the various issues to be concerned with in a separate article as well as possible ways to address those issues. With all technology solutions there are usually pros and cons so I first want to explain some of the pros and cons of scale out strategies.
Pros of Scaling Out
Once you have a working scale out solution you can usually bring on more servers easily if capacity needs grow suddenly, so it can be very attractive if the expected load is unknown or could increase quickly or unexpectedly. Solutions such as Windows Azure for example can be configured to automatically add nodes to the farm in response to traffic increases and reduce the nodes if traffic goes down.
While cloud services such as Windows Azure and Sql Azure can be relatively expensive to operate, it can also be economical vs buying your own beefy infrastructure of hardware since you would have to manage the hardware and software yourself and you could spend a lot of money and then not really get the amount of traffic to justify the costs of the purchased infrastructure. So it can be a safer bet to use cloud services which can be allocated or de-allocated easily as needed so that costs are inline with your actual usage.
Cons of Scaling Out
One thing to understand about scale out strategies is that while they can increase the total amount of traffic capacity that your site can handle it does not always improve performance in the way that scaling up does. For example using SqlAzure is going to be slower than using a local database server because it still must access the database over the internet, so while it can increase the total amount of capacity the perceived performance of loading web pages for individual requests can be a good deal slower than when the database is running on the same machine as the web server or a different machine on the same local network as the web server. So the scaled up site can seem a good deal faster to the users than a scaled out site. Therefore if your expected load is fairly well known so you aren't worried about reaching the capacity limit a scaled up system can handle a great deal of traffic and provide the best possible performance. So the important point here is that scalability is not the same thing as performance and people often confuse them as being the same thing. A site can scale well but not perform well and a site can perform well but not scale well enough to meet the demand for capacity.
Costs can be higher. While you do only pay for use when you have a web farm that allows easily provisioning or de-provisioning nodes in a web farm, this is high end hosting and it isn't cheap. The providers of these services are going to make a profit from the ongoing use fees. If your site doesn't really need this kind of hosting to meet capacity it can be overkill and it can cost more than you expected. I know of one person who started using SqlAzure for his mojoPortal site and it was not really a site that gets that much traffic so he really did not need SqlAzure and he was surprised when his bill was over $200/month for SqlAzure. In that case he was paying a premium and not getting as good of performance as he would have with just using a local SQL database. However there may be more complex strategies that can be employed to host locally on your own servers and then move to cloud hosting if there is some expected temporary increase in capacity need.
Created 2011-08-15 by Joe Audette