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.
For information on configuring the IIS 5 Isolation Mode, see the "Switching to IIS 5 Isolation Mode" section, p.38.
Many of the application pool parameters will affect the performance of your Web sites, and many will either affect or occasionally directly contradict the effects of another setting. For information on monitoring IIS and then tuning the various parameters, including their interactions, see (Chapter 5) p.97.
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.
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.
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.
Encrypted configurations are useful if you want to create complex, high-performance templates that can only then be installed by specific administrators.
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.
Use a descriptive name for the file in which you save your configuration to make it easy to identify later. You might want to accept a standard description format that orders things accordingly?for example, always specifying whether a pool template uses Web gardens or recycling.
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:
Open the root properties for the application you want to manage.
Go to the Directory, Home Directory, or the Virtual Directory tab (see Figure 2.5).
For directory or virtual directory sites, ensure that you have given the application a name.
Choose the application pool to use from the Application pool pop-up.
NOT NECESSARILY PLUG AND PLAY
If you thought IIS was just an install-and-forget-it thing, think again. Web applications deserve your attention, and taking the time to configure application pools will pay off in performance benefits.
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.
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.
With static pages, the server is really only reading a file off the disk and sending the data back to the client. This is a relatively light duty, so it takes little time to process. On a fast server, particularly one with two or more CPUs and employing multiple worker processes, you might be able to increase the values still further.
Built-in/Embedded ISAPI Filters
These have a slightly larger load because additional code and applications will be required to process the requests. The ideal setting is highly application specific.
ASP/ASP.NET implies a relatively high CPU requirement over static page provision, and therefore the value reflects this increased processing time. For simple applications, especially when using ASP for templating with the template caching option enabled, you could increase this to a value similar to that of the static pages. For solutions that process Web requests or provide interfaces to databases, keep in mind that the request time must include the time to process the DB request, as well as process the data and return the desired HTML.
Most CGI applications require the loading of an external process for the request to be processed. Starting a new application is one of the most intensive operations and so the load is significantly higher than an ISAPI based process.
For more information on the various performance parameters within IIS 6, visit www.samspublishing.com and enter this book's ISBN number (no hyphens or parenthesis) in the Search field; then click the book cover image to access the book details page. Click the Web Resources link in the More Information section and locate article ID# 020201.
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.
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.
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.
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
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.
Chapter 5 (p.97) contains further information on tuning these parameters for optimum processing.
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.
TEST! TEST! TEST!
Be sure to thoroughly test your applications and your worker process settings, especially the ping settings. You don't want to modify these settings on a production server and find out that you made a bad choice!
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.
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.
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.
For more information on the different users for use with IIS and their abilities, see "Security," (Chapter 3), p.39.
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.
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.
STATIC CONTENT DOESN'T RECYCLE
If you are only serving static content that does not require ISAPI extensions or filters, you shouldn't need to use the recycling system.
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.
MONITORING PROCESS RECYCLING
You can monitor when worker processes are recycled automatically by setting the LogEventOnRecycle property within the IIS Metabase. Suitable entries will then be made in WWW Service log.
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.
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.
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.
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.
For more information on Memory and DLL Management in IIS 5, visit www.samspublishing.com and enter this book's ISBN number (no hyphens or parenthesis) in the Search field; then click the book cover image to access the book details page. Click the Web Resources link in the More Information section and locate article ID# 020202.
If you want to change your server to run Web sites using IIS 5 Isolation Mode, implement the following steps:
Open the Properties dialog box for all Web Sites within your server.
Click the Service tab.
Select Run WWW Service in IIS 5.0 Isolation Mode.
You will be prompted to accept the change. Click Yes to continue.
ISOLATION MODE DISABLES WORKER PROCESSES!
This will disable worker process isolation mode because the two modes cannot co-exist. Any existing requests will be completed before the change takes place; although it won't interrupt existing requests, new requests might have to wait until the existing requests have completed successfully.
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.