Stress is a universal term that applies to both natural systems and computer systems. When a human feels stress, his coping mechanism differs according to the type of stress. When a Web farm experiences stress, its coping mechanisms differ according to the type of stress, too. A Web farm becomes stressed under many different scenarios. Some of the following items illustrate such stress factors:
Application changes and increased complexity can cause stress as new features and options affect the performance of a Web farm.
Increasing the number of servers can cause stress in other areas of the farm. Adding Web servers increases the connections to a COM+ cluster or SQL Server.
Site success can create stress when a user community grows beyond the planned capacity of a .NET Web farm.
Server failures and crashes can add stress to specific areas of a .NET Web farm, reducing the overall throughput until repairs are completed.
Scalability is a measure of a Web farm's capability to handle stress and the effort required to adjust overall site capacity on demand.
Handling Increased User Load
Increased user load occurs when a site gains popularity or during calendar-sensitive times like Christmas or the end of a fiscal quarter. Of course, meeting this demand is paramount because this is the time when a business earns the most money. To handle this stress and scale to meet the demand, most online businesses will have more server hardware than is required for normal business operations. The .NET platform's scaling strength is the capability to add server capacity seamlessly. It is through this "more is better" philosophy that the problem of single-server diminishing returns is eliminated. Where and how to add extra servers to a Web farm and whether an application can use this additional power are the main challenges when scaling to handle user load.
For example, Foo.com has a simple server architecture, shown in Figure 3.1. The Foo.com Web farm has a single Web server and a single database server. Foo.com has cyclic selling patterns, and during the last quarter users experienced delays in adding foo to their shopping baskets. When the administrators of Foo.com were watching the site, they noticed that the Web server CPU use was consistently 95%100%. They decided that the best thing was to purchase the fastest server available. This is called scaling up. Unfortunately, when the end of the next quarter arrived, they noticed the same CPU utilization problem. The number of users had doubled, but the single fastest server available was still not powerful enough to handle the demand.
Scaling up is accomplished by increasing the memory, CPU speed, network speed, and hard drive capacity of a single server to address bottlenecks in performance.
When facing a situation where scaling up is no longer an option on a single server, the .NET platform has an alternative: scaling out. Scaling out means creating a pool of servers that performs the same work as a single server. This is where the term "Web farm" originated. A herd of cows is equivalent to a farm of servers. For Foo.com, this means purchasing a second Web server identical to the original server.
Figure 3.1 Scaling up Foo.com's Web Server.
Scaling out is accomplished by increasing the number of servers in a layer of a Web farm.
Determining How to Scale Up
When facing a situation where a server is over utilized, there are four different scenarios to consider. Two of the utilization problems come down to a relationship between CPU and memory. In fewer cases, utilization problems can relate to I/O _bottlenecks. And even fewer problems relate to network throughput and performance. Knowing a few simple concepts can help an administrator diagnose these problems and make the right choice as to scaling up or scaling out.
In the first scenario, and the most common, the CPU utilization on a box under load with no application problems is stuck at 100%. In this situation, the CPU has too much work to do. There is adequate memory, and thus hard drive usage is not the problem. The only way to address this problem is to buy a bigger CPU or add a second one either to the same server or an additional server. With high CPU utilization situations, there will almost never be problems with memory, network speed, or disk space because the CPU has to wait on these devices and during these wait times cannot perform work. Thus, the CPU would not stay at 100%.
In the second scenario, the server is starved for RAM. In that case, the CPU will not be stuck at 100%, but it is likely the hard drive will be in constant use. This happens because Windows will use hard drive space like memory and swap memory sections in and out of RAM from one CPU request to another. When this happens, the box will perform slowly, but the CPU will not be the cause of the slowdown. The solution is to add more RAM if possible or add more servers.
In the third scenario, usually a problem found on file and print and SQL Servers is using all the I/O of a disk subsystem. The only way to tell this is happening is to monitor disk queue length with Performance Monitor. Disk queuing counters are not turned on by default, so consult the Windows Server help to determine how to do this for a particular server and disk subsystem. The only way to solve this problem is to increase I/O with a better system on a single server or multiple servers.
In the final scenario, usually only with wide area network links, inadequate network bandwidth can slow the performance of a server down considerably. This scenario is really separate from scaling up a server, as it is likely the real problem is with the physical pipe to an external or internal system. The only way to address problems like this is to increase the capacity of the network link.
Becoming a Web Farm
Transitioning from a single server Web site to a Web farm is not an easy task. Applications must be able to distribute functionality across multiple machines and layers. Networks must be able to handle increased traffic and physical connection points. Administrators must learn how to manage multiple servers and the software systems that allow scalability. Businesses must be willing to invest in faster and better hardware. Luckily, the .NET platform provides robust solutions for dealing with the complexity of scaling a Web site.
Scaling is accomplished by increasing the resources in a specific area that is experiencing stress. The majority of scaling technologies rely on creating a layer of abstraction between the source of the stress and the stress point. Usually this layer of abstraction begins in the network layer as these technologies circumvent TCP/IP addressing in one form or another. This type of technology is commonly referred to as "load-balancing."
Loading balancing works by abstracting the uniqueness of a network address (either a MAC address, an IP address, or a NetBIOS Name) to a software or hardware service. This service answers requests on that network address and then directs the traffic to multiple servers. This "balancing" effectively increases the number of physical machines that answer to a network name. When a collection of servers is balanced, these servers are referred to as a cluster. Figure 3.2 shows a Web farm with different types of clusters.
Figure 3.2 A simple load-balancing diagram with different clusters.
A cluster is a group of servers that act as one entity through software- or hardware-based balancing systems.
The original definition of a Web farm encompassed only the servers that provided HTTP services. The .NET Web farm has evolved into a collection of different cluster types. Just as a real farm has chickens, pigs, horses, and cattle, a .NET Web farm has Web clusters, COM+ clusters, SQL Server clusters, and other clusters.