Shared Static and Dynamic Hosting

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

The shared static and dynamic hosting strategy mixes static and dynamic sites on the same server. If your customer base requires you to host a mix of static and dynamic sites on the same server, the following guidelines can help you maximize the number of sites and application pools you can host on one server. Most of the guidelines in Shared Static Hosting apply to this strategy as well.

Separate static and dynamic content sites in different application pools

If you need to host static and dynamic sites on the same server, put the static sites in one or more application pools and the dynamic sites in one or more different application pools. By isolating the static sites from the dynamic sites, you mitigate the possibility of a poorly developed application crashing the static content application pool.

Set content quotas for sites

Your business model and customer service agreement should define content quotas, for example 200 MB for each site. Set disk quotas in the properties of each physical hard disk by using the Quota service available in Windows Server 2003.

Consider enabling Quality of Service (QoS) features for sites that are resource-intensive

Features such as CPU monitoring, bandwidth throttling, and idle timeout will ensure that one site does not consume a majority of the resources and cause errors for other sites on the same server. For more information about these features, including how to enable them, see Optimizing IIS 6.0 Performance.

Configure one unique anonymous user per site

Configuring one unique anonymous user per site adds a security layer by ensuring that users cannot access content on sites to which they are not permitted access.

Develop processes for handling service packs, security updates, and hotfixes

If your customers will be using IIS 6.0 to administer their own dynamic sites, set up a process for handling service packs, security updates, and hotfixes to minimize downtime for your customers and to help ensure the security of your installation. Windows Server 2003 has improved management of updates with Auto Update version 1.0, which provides you with three options:

• Notify you the moment an update is available.

• Download the update and notify you of its availability.

• Scheduled installation (this option enables the update to be downloaded and automatically installed at a time you choose).

For ASP content, allow ASP pages to run on MTA instead of STA

Because of the overhead memory and CPU cost of running dynamic applications, your server will reach a limit in the number of application pools it can host. With ASP content, you can mitigate this limitation on application pools by enabling ASP pages to run on multithreaded apartment (MTA) threads instead of single-threaded apartment (STA) threads. ASP is capable of running all of its threads in an MTA. If your COM components are primarily free-threaded or both-threaded, running the ASP threads as MTA can improve performance significantly. By default, the AspExecuteInMTA metabase property is set to 0, which means that ASP does not execute in MTA. Set this property to 1 at the application level to enable ASP to run in MTA.

If you need to set up more than 60 application pools where each pool is running as a unique identity on a server, change the UseSharedWPDesktop registry key

If you are setting up your application pools with unique identities, depending on the applications and memory resources on your server, you will reach a limit of about 60 application pools. There are finite limits to some system resources that get allocated with each new logon session. This means that 60 processes can run concurrently as distinct accounts. IIS 6.0 supports running these processes in a single shared workstation and desktop, at a cost of sharing a single encapsulation of a user session among all parties.

To scale beyond 60 application pools and to share a single desktop, change the value of the registry entry UseSharedWPDesktop, of data type DWORD, to 1. The registry entry is located in the subkey HKLM\System\CurrentControlSet\Services\W3SVC\Parameters\UseSharedWPDesktop. After changing this registry entry, you should be able to scale to hundreds of application pools and hundreds of concurrently running worker processes.

If IIS is starting too many worker processes and your server is running out of resources, set a maximum number of concurrent worker processes

With the IIS 6.0/HTTP.sys architecture and with a request load distributed across many application pools, IIS might attempt to start more worker processes than the server can sustain without running out of memory or CPU resources. The DemandStartThreshold Metabase Property (also called concurrent process gating), when set to a value less than the default, applies a hard limit to the number of IIS worker processes that can run concurrently. If the hard limit is exceeded, HTTP.sys returns an HTTP 503 error (Service Unavailable).

Locate misbehaving applications and isolate them in their own application pool

You can use Event Viewer and IIS logs to locate misbehaving applications, or you can use Log Manager and Trace Report, which are general-purpose tools supplied with Windows Server 2003. Log Manager creates trace data, which is then processed by the Windows Trace Report utility. The Trace Report utility creates a formatted, detailed report that is useful in assessing IIS and IIS-related activity in the operating system. Once you have located a misbehaving application, isolate the application in its own application pool so it doesn't affect other applications. Recycle the application pool regularly.

Related Topics

For more information about editing the registry, see the Registry Reference.

For more information about Log Manager and Trace Report, see The IIS Request-Based Tracing Process.

For more information about viewing and interpreting log files, see Analyzing Log Files.