This documentation is archived and is not being maintained.

Performance Application Pool Settings

.NET Framework 1.1

The performance application pool settings allow you to control the operation of the worker process. The following sections describe how to specify performance application pool settings.

Specifying Performance Application Pool Settings

The performance application pool settings are specified on the Performance tab of an application pool's properties dialog box.

To set the performance application pool settings

  1. Open the IIS management console and expand the local computer by clicking the plus sign.
  2. Expand the Application Pools folder by clicking the plus sign.
  3. Right-click the appropriate application pool and then click Properties. The application pool's properties dialog box appears.
  4. Click the Performance tab, and then set the appropriate application pool settings.

Performance tab of the application pool Properties dialog box

Aa720391.performance(en-us,VS.71).gif

Web Garden

Web garden is the equivalent application pool setting for the webGarden and cpuMask ASP.NET process model settings. To enable Web garden, set the Maximum number of worker processes to a value higher than 1. This value also determines the maximum number of processes for the application pool.

Because Web gardens enable the use of multiple processes, each process will have its own copy of application state, in-process session state, caches, and static data. Web gardens should not be used for all applications, especially if they need to maintain state. Be sure to benchmark the performance of the application before deciding whether Web garden mode is appropriate.

When using a Web garden, it is important to understand how session state and round robin works. It is also important to consider of how other application pool settings affect the application.

Session State in a Web Garden Using Worker Process Isolation Mode

When using session state, be aware that worker process isolation mode does not support routing requests back to a process that originated the request back. When an application is running under a Web garden with ASP session state or application state, the application needs to have its requests sent back to the originating process. When using the IIS 6.0 application pooling, make sure the application keeps a connection open so that its requests are sent back to the appropriate process. If the connection is not kept open, the request will be sent to the next available worker process servicing the Web garden.

Round Robin in a Web Garden Using Worker Process Isolation Mode

Round robin is a method of load balancing for the application. As each request arrives, it is automatically sent to the next sequential process. For example, if a Web garden has 4 processes, requests are sent to processes 0, 1, 2, and 3, in that order. The cycle is then repeated for additional requests.

Application Pool Parameters in a Web Garden Using Worker Process Isolation Mode

Some application pool settings have Web garden–specific behavior. The following table summarizes these behaviors.

Application pool settingBehavior
AppPoolQueueLengthThe value of this parameter is not affected. However, requests are distributed by round robin across the worker processes servicing the Web garden.
DisallowOverlappingRotationNo behavior change in a Web garden.
DisallowRotationOnConfigChangeNo behavior change in a Web garden.
IdleTimeoutIndividually calculated for each process, so that each process times out independently. Depending on which routing algorithm is chosen, the number of processes will automatically configure itself to the load.
LoadBalancerCapabilitiesNo behavior change in a Web garden.
OrphanActionNo behavior change in a Web garden.
OrphanWorkerProcessNo behavior change in a Web garden.
PeriodicRestartTimeThis parameter has a changed meaning in a Web garden. In a Web garden, this parameter specifies the time interval in which all processes are recycled. Processes take turn recycling at even intervals within the specified time amount. For example, if a Web garden has four processes and the PeriodicRestartTime is set to 20 hours, the first process is recycled after five hours, the second process is recycled after 10 hours, and so on.
Note   If a process crashes, the replacement process is given a run time value of PeriodicRestartTime. This allows the process that crashed to recycle, along with other processes, within the specified PeriodicRestartTime.
PeriodicRestartRequestsThis parameter has a changed meaning in a Web garden. In a Web garden, this parameter specifies that all processes are recycled after a certain number of requests. Processes take turn recycling at even intervals within the specified number of requests. For example, if a Web garden has four processed and the PeriodicRestartRequests is set to 40,000 requests, the first process is recycled after 10,000 request, the second process is recycled after 20,000 requests, and so on. After the initial processes are recycled, the next set of processes is assigned a PeriodicRestartRequests value of 40,000.
PeriodicRestartScheduleNo behavior change in a Web garden. If an administrator decides to use schedule-based recycling, all Web garden processes are recycled at the same time.
PingIntervalNo behavior change in a Web garden.
PingResponseTimeNo behavior change in a Web garden.
PingingEnabledNo behavior change in a Web garden.
RapidFailProtectionNo behavior change in a Web garden. For example, the total failures across a Web garden are calculated and then compared over a time interval. This provides and additional level of resilience.
RapidFailProtectionIntervalNo behavior change in a Web garden. For example, the total failures across a Web garden are calculated and then compared over a time interval. This provides and additional level of resilience.
RapidFailProtectionMaxCrashesNo behavior change in a Web garden. For example, the total failures across a Web garden are calculated and then compared over a time interval. This provides and additional level of resilience.
SMPAffinitizedNo behavior change in a Web garden.
SMPProcessorAffinityMaskIn IIS 5.0 isolation mode, you can have only as many worker processes as CPUs. In worker process isolation mode, multiple CPUs can service a single worker process.
ShutdownTimeLimitNo behavior change in a Web garden.
StartupTimeLimitNo behavior change in a Web garden.

Idle Timeout

Idle timeout is the equivalent application pool setting for the idleTimeout ASP.NET process model setting. It specifies the amount of time before a worker process or application pool is shutdown due to inactivity. Idle timeout is enabled and set to 20 minutes by default. You can specify a different time limit by changing the value in the spin box. To disable Idle timeout, clear the check box.

Request Queue Limit

Request queue limit is the equivalent application pool setting for the restartQueueLimit ASP.NET process model setting. It specifies the maximum number of requests that are queued in the ASP.NET ISAPI while waiting for the worker process to start after an abnormal termination. Request queue limit is enabled and set to 1000 requests by default. You can specify a different limit to the number of requests queued by changing the value in the spin box. To disable Request queue limit, clear the check box.

See Also

Application Pool Settings for Worker Process Isolation Mode | Recycling Application Pool Settings | Health Application Pool Settings | Identity Application Pool Settings | IIS 6.0 Application Isolation Modes | IIS 6.0 Application Isolation Modes Overview | Mapping ASP.NET Process Model Settings to IIS 6.0 Application Pool Settings | <processModel> Element

Show: