Configuration

Although they've been portrayed here as separate components, HTTP.sys, applications pools, and worker process are all configured through the same basic set of interfaces within the IIS management snap-in for the MMC.

The majority of the configurable settings available to you for IIS 6's core architecture are useful only when working in Worker Process Isolation Mode. Unless otherwise noted, all the configurable options in this section relate to using IIS 6 in this mode.

Application Pool Management

Application pools are configured directly within the IIS snap-in of MMC. You can see the default IIS configuration panel, with a number of sites and application pools already configured, in Figure 2.3.

Creating and Naming Application Pools

To create a new pool, right-click on the Application Pools folder and select New, Application Pool. You'll see the dialog box in Figure 2.4.

You need to enter the application pool ID?just a name to identify the pool. You can opt either to use the default settings or to copy the settings from an existing pool.

Once created, the new pool appears in the list of available application pools in the IIS browser. The majority of the configurable parameters within each pool apply either to the request queue component or to the management of worker processes; we'll look at those elements individually.

Using Templates

If you are setting up a number of application pools, you can use predefined templates in one of two ways. Either select the name of an existing application pool whose settings will be copied, or you can save your application pool settings to a file and use the file to generate new application pools. The latter method has the benefit that you can create application pool types without having to actually activate a particular pool for use as a template.

To save an application pool template to a file, create a new application pool in the standard way, right-click on the pool, and then select All Tasks, Save Configuration to a File. You will be prompted for a filename and a path in which to save the file. You can also optionally encrypt the configuration by entering a password.

To create a new application from a template file, right-click on an application and select New, Application pool (from file). You will be prompted for a filename, or you can browse to a directory of existing configurations and select your choice from a list.

Allocating Sites to Pools

Application pool allocation works in a similar fashion to the Application setting within IIS 5. To set a specific application to a specific pool, perform the following steps:

Starting and Stopping Pools

You can start, stop, or recycle an entire application pool by using the options in the drop-down menu when you right-click on the pool you want to manage:

Start will start a currently stopped pool.

Stop will stop a currently running pool, enabling all applications that use this pool.

Recycle will shut down and then restart all the worker processes within the pool.

Remember that stopping an application pool will stop processing of all requests for an application that uses that pool. If you are having persistent problems with a particular application or pool, use the monitoring and recycling features to manage the application pool automatically.

Request Queue Parameters

Only one configurable parameter exists for the request queue component, and it is found under the Performance tab of the properties for an application pool.

If selected (it's on by default), the Request Queue Limit allows you to specify the number of requests that will be queued. When the queue is full, the application will respond with the HTTP error 503 (Server Unavailable) to clients.

If you don't set this option, or you set the number of requests to accept too high, a potentially unlimited number of requests could bog down your application pool and ultimately your server, bringing it to a grinding halt, irrespective of what other settings you have in place.

Set the value too low, and you risk locking out users from your server when it potentially isn't even busy.

The value you set depends entirely on what applications the pool is servicing and what your expected response times are. The aim is to keep your request at a level that never enables the pool to reach your desired maximum request time. For example, if you set a target of a five second response, you should set a limit that processes a full queue within that period.

For some hints on some typical values for different situations, see Table 2.3. Although I've given specific figures, ideally you should really compare the relative sizes between applications. Keep in mind that different applications will imply different processing times and therefore request queue sizes.

Worker Process Parameters

You can configure the number of worker processes started by an application pool using the Web garden settings in the Performance tab of the pool's properties. The default for a new pool is to use only one worker process.

The exact setting of this parameter depends on a combination of the underlying hardware, the loading effects of your application, and the total number of application pools configured in your system. In general, it's not recommended to have more than one worker process per CPU for each configured application pool.

Performance Parameters

The Performance tab, shown in Figure 2.6, configures the core performance settings for your application pool. I've already covered the request queue and Web garden parameters separately; the other two settings control the idle timeout and CPU loading.

CPU Loading

It's possible to limit the amount of CPU used by an application pool. Throttling the application pools in this way can be useful if you are mixing customers who have different site response time requirements, or if you are hosting a number of sites over a number of individual pools and want to avoid one pool absorbing all the available resources.

This setting is similar to the process throttling setting in IIS 5, but is more configurable and works on an application pool rather than a Web site basis. By controlling individual pools in this manner, you can set up a number of specific pools?for example, four pools with 5%, 15%, 25%, and 55% throttling and redistribute groups of sites according to needs.

In addition to setting the maximum CPU usage for the pool, you can also configure the period over which the usage is monitored. (The default is five minutes.)

As with IIS 5, we can also control what happens when the limit is reached. The available actions are the same as under IIS 5:

No action? Nothing happens except the logging of the event. This is equivalent to leaving the Enforce Limits unchecked under IIS 5.

Shutdown? All worker processes within the application pool are marked for termination and allowed to shut down within the Shutdown Time parameter limits. This is equivalent to checking the Enforce Limits box under IIS 5.

Idle Timeout

Worker processes require tiny amounts of processor time and memory even when they are not actually processing requests. On a server that hosts a number of low-volume Web sites, the potential exists to create hundreds or thousands of worker processes that are doing nothing, reducing the server's capability to service other requests.

Using this parameter, IIS will monitor inactive worker processes and shut down those that have been idle for the specified period. The default is 90 seconds. As soon as a request is made to the application pool, a new worker process is started.

Obviously, starting a new process has an implied overhead, so you don't want to have worker processes always having to be started automatically through this system because this will slow your response times.

You might want to lower the shutdown time period in the following situations:

• Sites that have low-traffic volumes, but occasional high bursts for short periods (for example, a report generation system run once a month)

• On servers that have a high number of low-volume sites where you have created one pool per customer

• Sites that have sporadic access but overall low volume

You might want to increase the time period when you have

• A relatively busy site with occasional dips in usage

• A low volume, but regular usage site

Health Monitoring Parameters

The health monitoring features of an application control how the pool responds to problems with individual worker processes. The aim of tuning these parameters is to provide a balance between worker process availability and keeping idle worker processes to a minimum.

You can see an example of the Health tab in Figure 2.7.

Enable Pinging

If you enable this setting, individual worker processes will be tested to verify their responsiveness. If the worker process fails to respond, the worker process is recycled, killing the failed process and re-creating a replacement. You can specify the delay period (the default is 30 seconds) between each ping using the box provided.

You should change this setting with care because it has the potential to kill perfectly healthy worker processes if set incorrectly. Setting too low a value might cause the system to recycle a process that is simply busy processing a request. Setting too high a value could leave a crashed process running. In a single worker process environment, this could stop your Web site completely. Even in Web garden installations, the crashed process could present a serious performance hit.

Enable Rapid-Fail Protection

Because worker processes execute user code, the potential exists that a problem in the user application could cause continual failures, requiring the worker process to be re-created. Unless you were continually checking this, you would probably never notice, but the effects of the problem are two-fold.

First, your system becomes excessively busy without ever achieving anything because the load of starting a new worker process each time one fails?potentially many times every second on a busy site?is quite high. Second, many of your client requests will either be processed, terminated in mid-response, or your site might have stopped responding altogether. It will be impossible, as a client, to identify what the problem might be.

To help resolve this, rapid-fail protection will monitor worker processes over a given period, and if the processes fail a set of number of times in this period, the application will be disabled, causing HTTP.sys to return a 403 (service not available) error rather than continuing to service requests for an obviously faulty application.

There are two settings?the time period over which the checks will take place and the number of failures that have to be registered within that period. Setting these limits needs careful consideration:

• Setting too high a failure rate within a short period of time is unlikely to trigger protection because there is a finite failure/recycle rate for worker processes.

• Setting too low a failure rate within a long period might also never trigger protection.

As with other parameters, the settings need to be tuned both according to the application and with the expected response time of the application in mind. To put this into context, if it takes 10 seconds to process a request, setting parameters of 30 failures in 5 minutes is impractical.

Instead, work on a percentage failure rate?for example, you might want to trigger protection if the failures exceed 10% of requests at typical load within a 5 minute period. In this instance, a setting of 3 failures within 5 minutes would be appropriate.

Startup and Shutdown Time Limits

When worker processes are recycled, or after being identified as unhealthy, they are not terminated immediately. Instead, the process is marked for termination and given a grace period to complete the processing of any outstanding requests.

The Shutdown time limit parameter defines the duration of the grace period. The time limit needs to be set carefully so that you do not terminate execution before any outstanding requests have been processed. For example, for an application that has an average response time of 10 seconds, you should set a figure below 30 seconds to avoid terminating in-progress applications.

The Startup time limit defines the period in which a new worker process must start before it should be ready for handling requests. Failure to startup within a given time frame will be recorded and if necessary used in the rapid fail protection system to prevent an application from starting up in an unstable condition.

Identity Parameters

All worker processes within a given application pool are executed as the same user. You can configure which user this is using the Identity tab of the application pool properties.

The default user is the Network Service account, which has the least user rights, required to execute Web applications. It's therefore the safest user to use because it provides the least number of opportunities for a cracker to gain access to your system.

Other selectable options are

Local Service? Similar to Network Service, but with rights only for the current machine.

Local System? The least secure option, this user gives almost unlimited access to the host system. Do not use unless you are either using a test system not connected to your internal network, or use sparingly with applications that use both SSL and some form of authentication.

Alternatively, you can use any user on the system providing you supply his username and password. Note that any user you choose should be a member of the IIS_WPG group; otherwise, the application pool will fail.

Depending on your configuration, you might want to use the default Network Service account. The primary reason for using an alternative account is to compartmentalize individual users.

Recycling Parameters

Often, even with a well-behaved application, the potential exists for the application to start using more resources than it should. Sometimes, you might even have applications that either you cannot fix or cannot identify the problem that needs to be fixed.

Previously with IIS 5, you'd either have to manually monitor the system or alternatively use IISReset or a VB, Perl, or other application to periodically stop and restart the Web service. In either case, you run the risk of disabling all of your sites from your potential visitors during the cycle.

In IIS 6, the capability to schedule a recycle of the worker processes handling requests for an application pool is built in. Because of the changes to the request system and application isolation, individual worker processes can be restarted without affecting the availability of individual sites or applications, or the IIS system as a whole.

The recycling system recycles worker processes in one of two ways:

In low-load conditions, where very few requests are being handled by the application pool, the existing worker process will be terminated and a new one started in its place.

In all other situations (and indeed the default configuration), a new worker process is to be started while the existing process still processes requests; when the new worker process is ready, the new one takes over and the old one is terminated.

Using this approach keeps the application pool busy servicing requests without losing any availability?there's no period of time when a given pool is unable to service requests.

Worker processes are configured through the Recycling tab of the application properties window. You can recycle parameters according to a number of different settings. If you specify more than one setting, the settings are combined?with processes recycled by whichever method triggers the recycle process first.

For example, if you recycle by request and duration, the recycling will be triggered if the process reaches the request limit before the duration expires, or if the duration expires before the request limit is reached. After a worker process has been restarted, all counters are reset, irrespective of the trigger.

Regular Time Period

Worker processes can be automatically recycled after they have been executing for the specified number of minutes using the Recycle Worker Processes (in Minutes) setting. If you use this setting with a Web garden, the restarting of individual processes is staggered to retain uptime, but all processes in the application will be restarted within the given time frame.

The duration setting is the most practical of the settings in situations where you suspect a problem that is non-fatal or not serious enough to warrant strict checking. If you are having an intermittent problem, use this setting in combination with the health monitoring parameters so that you can both pre-empt and recover from potential problems.

Regular Request Period

The regular request period setting?Recycle worker processes (number of requests)?triggers recycling when a worker process has handled the specified number of requests. For example, setting a value to 500 would automatically restart the worker process after it has handled 500 requests.

This setting is best used with applications where you know it has a specific problem, perhaps a memory leak, that manifests itself at a particular execution limit. For example, an application that gradually eats RAM could be set to recycle before it uses too much. You might also want to consider the Memory Recycling settings.

Specific Times

If your Web site has well-defined usage and you have known gaps or deliberate administration downtimes, you can set the recycling to occur at specific times. To use this setting, first click the check box, and then click Add to specify a particular time. Existing times can be removed using Delete, and you can modify an entry using Edit.

As with the duration setting and Web gardens, worker processes are not recycled simultaneously, but instead staggered around the times you specify to prevent the application pool from failing to handle a request.

Memory Recycling

User applications with problems frequently exhibit memory leaks, which use virtual and physical memory that could otherwise be allocated to other worker processes. These are finite resources, so it's a good idea to protect their usage by enabling these settings.

Unlike the other settings, the memory settings apply to individual worker processes within a given application. If one worker process reaches the specific limits, it's the only process that is recycled; other processes will continue to execute as normal. This makes these settings ideal for controlling memory usage if all the other problems with an application do not affect execution.

Be very careful with these settings, however. Some applications can genuinely require large amounts of memory?for example, database applications that generate large queries. Setting the values too low could increase the load on the system by generating too many recycling triggers. Conversely, setting the figures too high can mean that the recycle is never triggered, even though the effects could be having a detrimental affect on your system.

You can tune these parameters through careful monitoring of the worker process memory size and your available virtual and physical memory. Alternatively, try to avoid using more than 50% of either setting across all your application pools. For example, with 4GB of virtual memory and two application pools, you would set a limit of 1GB on each pool before a recycle is triggered.

Switching to IIS 5 Isolation Mode

If you want to change your server to run Web sites using IIS 5 Isolation Mode, implement the following steps:

From then on, most parameters work as they did in IIS 5. For example, to configure application isolation modes, you use the Application Protection setting in the directory, home, or virtual directory tab of the Web site's properties.

Most significant of the parameters that disappear from IIS 5 Isolation Mode is the CPU throttling parameter. There is no way to configure this setting when the machine is in IIS 5 Isolation Mode.

The option to configure individual application pools in your system will disappear. In fact, you won't even be able to select an application pool. Your settings will be retained though, so if you disable IIS 5 Isolation Mode, your application pools and their configurations will return.