[This is preliminary documentation and subject to change]

# About Scalability

Web administrators are concerned with scalability because they need to make certain their Web presence can handle steady traffic growth as well as unanticipated traffic volumes. If the software and the underlying infrastructure do not scale, then the server and the clients connecting to that server will experience errors or problems. Internet Information Services is designed to scale, though poorly-designed infrastructure configurations can undermine the software. This topic describes methods of hardware scaling and how to design scalability into your entire infrastructure so that your IIS server performs optimally.

Note Consider enabling Dedicated Application Mode. Dedicated Application Mode forces applications to run in an isolated environment. Isolating applications in this way reduces bottlenecks and points of contention, which typically improves scalability and performance.

This section includes the following topics:

- Methods of Scaling
- Designing Scalability into the Server Environment

## Methods of Scaling

Improving the scalability of your IIS Web server environment requires planning and design with regards to hardware and infrastructure. Because IIS is designed to scale, administrators typically need to concern themselves only with the infrastructure. When planning how to improve the scalability of the infrastructure, administrators can choose to scale up, scale out, or scale down. The method you choose depends on the type of information you intend to publish/process and your budget. Each method has benefits and drawbacks.

Note Performance and scalability results will vary. Every server environment is different, therefore this table suggests only general performance and scalability results. See the individual topics for more details.

Infrastructure Scalability Methods

Method | Process | Performance Results | Applications | Cost | Scalability Results
--- | --- | --- | --- | --- | ---
Scaling Up | Add hardware like RAM or CPUs to an existing server. | Moderate | Must be highest quality in design; ideally C or C++. VB apps are discouraged. Greater potential for a bad application to crash a site. | Low | Average May enable an IIS Web server to house a few thousand more sites. Economical way to publish large amounts of static content.
Scaling Out | Add servers to an existing server environment. | High | Server environment can handle lower quality apps without sacrificing performance and scalability. VB apps are acceptable. | High | Excellent Good option for sites processing financial transactions or binary large object downloads (BLOB).
Scaling Down | Replace real sites with virtual sites and assess idle capacity in order to combine resources. | High | Not a good option for sites that utilize line-of-business or distributed applications. Best suited for sites with large amounts of static content. | Reduces Cost | Good Scaling down may be a vital solution for an ISP hosting thousands of sites inefficiently.

## Designing Scalability into the Server Environment

The scalability of your system is dependent on the least scalable part; if one piece fails, the scalability of the whole system suffers. Scalability in a Web server environment can only be achieved if it is designed into every facet of the system. The entire infrastructure, including hardware, software, filters, custom components, and applications must scale. For this reason, improving scalability requires long-term assessment, planning, and relentless testing. Typically, administrators can not build a scalable Web presence and underlying infrastructure on their own; they have to work with designers and managers through every step of the process--conception to production. How you scale and the method you choose to scale depends largely on the goals for your Web presence and your budget.

From a high level, designing scalability into your system requires that you:

### Define the long term objectives for your Web Presence

The long term objectives for your Web presence are probably determined by the nature of your business. Internet Service Providers (ISP) want to host as many sites on one server as they possibly can while maintaining performance. Ecommerce sites want fast and efficient processing of financial transactions through secure connections. If you are using IIS for your intranet, then your long term objective may be to place all of your Human Resources benefits and payroll forms on your intranet. Defining your objective will help determine how you build your infrastructure. For example, an ISP hosting thousands of static sites may achieve great scalability with very low overhead cost by Scaling Up. A large e-commerce site connected to an extensive database and processing financial transactions will have better luck Scaling Out because lock contention is reduced and because there are more resources to handle the workloads.

### Know your customers

Determine what your customers want and how they'll be getting at your site's products and services. For example, are your customers accessing your site through a T1 connection or a 56K modem? If the products and services offered on your site require large amounts of bandwidth to be viewed or experienced properly, then you may frustrate a large population of potential customers. Also, the strain of sending large image files or music files to a 56K modem will undermine the performance and scalability of your system for other users. Design your site so that users connecting with a 56K modem will still have a rich experience.

### Define your design goals with scalability as a priority

Make certain that all parties involved in the development of your Web presence understand that scalability and performance are to be designed into the server environment. Establish plans for redundancy/failover capabilities and consider designing your server environment according to the following guidelines:

- Strive for consistency across your entire code base.
- Make configurations simple.
- For sites offering special services or features, make certain the site is configurable by feature. If adding a new features compromises scalability and performance, pull the feature out and fix the bugs in a test environment.
- Strive to minimize the number of round-trips between the middle tier and the backend.
- Optimize data flow.
- Consider a distributed architecture and distributed applications.
- Consider offline processing.
- Make specific error events consistent across features; meaning, use the same error code for issues requiring similar fixes.
- Define standards for rendering, writes, membership, and notifications.
- Utilize services that already exist.

### Test the Server Environment and Client Connections

Perform client testing to verify the site works and works as it was designed. Test the infrastructure at twice the expected load. Know what the servers look like under load, the limits where the server goes down, and what you can do to prevent the server from failing. When preparing your production servers, perform a scriptable install across the platform for consistency and to reduce human costs.

### Keep Lines of Communication Open

Administrators need to keep a clear line of communication back to designers and testers for efficient troubleshooting. Know when it's time to scale with hardware or software versus a redesign of site features.

Related Topics

- For more information about monitoring and improving server performance, see Performance Monitoring.

© 1997-2001 Microsoft Corporation. All rights reserved.