Scaling the Web Tier

Scaling the Web Tier

Scalability is defined as having the ability to add resources to a system that increase its performance (decrease response times or increase throughput). From the performance testing perspective, this means adding more hardware or redesigning your Web application to allow more users to access your Web application more efficiently. To cover scalability we will focus on the Web tier and a methodology to know when and how to scale it.

Scale Out, Scale Up, or Performance Tune?

The term scalability typically is covered by two distinct yet similar methods, scaling up and scaling out. These methods should only be used after your Web application has been performance tested and performance tuned. Performance testing helps you identify bottlenecks and limitations of your current Web application. Through performance tuning you will increase throughput, decrease your response times, or both. The following list definitions and the pros and cons for scaling out, scaling up, and performance tuning.

Scaling Out

Scaling out your Web tier is adding extra Web servers to your application to overcome a bottleneck or limitation caused by this tier. The benefit of scaling out your Web tier is an increase in throughput, provided there are no network, SQL, or other bottlenecks external to your Web server. The downside of scaling out is that it can be expensive in terms of hardware cost, software cost, and production support cost (power, rack space, cooling, and so on). Additionally, this puts more of a burden on support staff and deployment.

Scaling Up

Scaling up your Web tier means adding extra hardware like memory and CPU capacity to your servers to overcome a bottleneck or limitation caused by this tier. This method is less expensive then scaling out because memory and CPU costs are relatively inexpensive compared to buying the whole machine. However, this approach may not give you linear gains in performance. To justify scaling up, performance testing is required both before and after scaling up to determine the overall impact.

Performance Tuning

Performance tuning is simply fixing bottlenecks on your application to achieve your desired throughput rate or response time criteria. In other words, fix the code instead of scaling your hardware. This method can be the most expensive if not performed during the software development life cycle, because it involves high labor cost for software developers, test engineers, and support engineers.

When to Scale your Web Tier?

A common mistake when building and deploying a Web application is using an unnecessary amount of hardware to solve issues and overcome bottlenecks. Performance tuning your application will save time and money because it can give you a better idea of when additional hardware via scaling up or scaling out is required. By using steps detailed in Chapter 2, you can identify the business requirements for the approximate number of customers who will access your Web application. Then you can run performance tests and tune your Web application to meet and exceed these estimates. You can also perform a transaction cost analysis, which is outlined in Chapter 9, to determine the maximum number of users your Web application can handle and to help with capacity planning

You should scale your Web tier only after all other performance constraints are identified and resolved. For example, if your SQL tier has several performance issues that limit the number of users to a quantity that a single IIS Server can handle you should fix your SQL issues first. There is no point in scaling out your Web tier by adding more IIS servers or upgrading your existing servers with more and faster CPUs and memory if your SQL tier is at peak capacity.

How Big is Big Enough?

Say you are in the travel and cruise ship industry and you are trying to determine what is the largest ship possible to obtain the maximum number of customers. If you scale your ship out and up too much to accommodate as many passengers as possible, you may not be able to travel to certain places that have size limitations, like the Panama Canal. If you are not sold out for every trip the unnecessary space and weight may cause your business to incur extra expenses. The best approach would be to build the ship to meet your peak passenger and profit requirements with five percent extra capacity perhaps. This same principle applies when you are trying to determine how much hardware is needed to deploy a Web application.

How to Scale Out your Web Tier?

To have fault tolerance and redundancy every Web application should have a minimum of two Web servers. You may build redundancy into a single machine but just having one Web server limits your application to a single point of failure. The simplest way to scale out your Web tier is by adding additional Web servers and to use a hardware or software based load balancing solution.

Software-based Load Balancing

Microsoft s implementation of a software-based load balancing solution is called Network Load Balancing (NLB). Using NLB is typically the least expensive method of load balancing and uses services bundled in Windows 2000 Advanced Server, Windows 2000 Data Center Edition, and Windows .NET Server. This method is good for most Web applications and allows you to scale out several nodes in your Web tier. For detailed instructions and implementation practices visit http://www.microsoft.com.

Hardware-based Load Balancing

A hardware-based load balancing solution is optimal because it is a layer separate from your Web application s code, so it does not use resources from your Web server. Many companies, such as Cisco, F5 Labs, and Extreme Networks, provide hardware-based load balancing products and solutions. For detailed information on configuring and installing a load balancing solution, visit the Web sites of the vendors listed above.