Shared Static Hosting

Applies To: Windows Server 2003, Windows Server 2003 with SP1

The shared static hosting strategy involves collecting large numbers of static sites together on one server. These static sites are typically personal home pages or business pages that experience very low traffic volumes on a daily basis, so performance and scalability issues are rarely an issue. Before provisioning your server, consider the following guidelines.

Administer IIS by using command-line administration scripts or batch files

Using IIS Manager to perform tasks such as provisioning thousands of new sites or configuring sites is extremely inefficient. If your server hosts a few thousand sites, IIS Manager can take several minutes to refresh as it reads configuration data from the metabase. In this case, it is more efficient to administer IIS by using command-line tools. For information about command-line administration tools in IIS 6.0, see IIS 6.0 Administration Scripts, Tips, and Tricks, or see Using Command-Line Administration Scripts. For general information about Web site and virtual directory configuration, see Configuring Internet Sites and Services.

Create a logical folder structure

A logical folder structure, for example Domain/username, will alleviate some of the administration overhead in locating sites when they require configuration changes.

Use host header names to create multiple sites on one server

Static IP addresses are in limited supply, and obtaining thousands of static IP addresses can be problematic. Static IP addresses are only necessary when a site requires Secure Sockets Layer (SSL). Also, static IP addresses have performance overhead costs. The WWW service must manage an endpoint for every site identified by a unique IP address, and this consumes memory from the nonpaged pool.

Put all static sites in one application pool

Static sites, if they are truly static, pose little or no crash risk for an application pool because static sites do not execute code. By putting the sites in one application pool, you limit the resource overhead that multiple application pools impose. You also limit the administrative overhead that comes with multiple application pools.

Run all static sites with the same anonymous user account

For static, public Web sites, the anonymous user account provides ample security. Before returning a page to the client, IIS checks NTFS file and directory permissions to see whether the IUSR_computername account is allowed access to the file. If access is not allowed, IIS attempts to use another authentication method. If none is selected, IIS returns an HTTP 403 error (Access Denied) to the browser.

Recycle the application pool worker process (optional)

You will need to monitor site traffic to determine a regular recycle schedule, if a regular recycle is needed. Ideally, you should recycle the worker process during low-traffic times, for example 3:00 A.M. local time. For more information about worker process recycling, see Running IIS 6.0 as an Application Server.

Monitor startup times

Although you should not need to restart your server very often, monitor startup times when you do restart the server. When an IIS server hosts thousands of Web sites, the size of the metabase grows significantly and the task of reading configuration data from the metabase while IIS is starting can strain your CPU resources. Your startup times might be a determining factor for when you need to add a new server to your installation**.**

Monitor performance

As you provision sites, regularly monitor site traffic and resource consumption. In this way, you will be able to see how the system scales and proactively determine when it is time to add a new server to your installation.

Enable centralized binary logging

Centralized binary logging writes all log file data in binary format to one centralized file, and preserves memory and CPU resources by not creating and writing to thousands of individual log files. For more information about centralized binary log files, see Analyzing Log Files.

Partition log files on multiple disks

If you choose not to use centralized binary logging, partition log files on multiple disks to minimize I/O. With multiple disk controllers writing log data to different disks, you will minimize I/O and preserve memory resources for other needs.