Managing, Tuning, and Configuring Application Pools in IIS 7.0

The Microsoft Engineering Operations (MSCOM Ops) team uses both integrated and classic requestprocessing to manage application pools in Internet Information Services (IIS) 7.0 to optimize performance and improve site availability at www.microsoft.com. In this article, we discuss how we leverage the benefits of the integrated requestprocessing mode, describe the configuration settings that we use to tune application pools, and explain which configuration changes result in application pool recycling. We also provide examples that demonstrate how you can configure application pools by using the appcmd.exe command line tool and IIS Manager.

Using Integrated and Classic Request Processing Modes

Microsoft® Windows Server™ 2003 and IIS 6.0 introduced the ability for Web administrators to create custom application pools in addition to the default application pool for Web sites. Each application pool functions as a separate process in its own isolated allocation of virtual memory address space. By using application pools, you can individually segregate or consolidate applications into logical groupings. For example, you can place a critical application in its own application pool to limit the possibility of another application adversely affecting its performance. Conversely, you can place a known poorly performing application in a dedicated application pool to limit the possibility that it will adversely affect the performance of another application.

If a particular application pool has reached the specified threshold for a forced restart, the operating system recycles the application pool in a graceful manner. For example, before the application pool is taken offline, a new process is created. Requests are routed to the new process and the old process is allowed to run to finish processing outstanding requests until it reaches its shutdown time. When the new application pool is initialized, it registers its URLs with Http.sys and starts servicing them. This process is called overlapped recycling.

IIS 7.0 introduces two request processing modes for application pools: integrated mode and classic mode. When you configure an application pool to run in integrated mode, IIS 7.0 processes requests for managed content by using the new integrated IIS and ASP.NET request processing pipeline. When you configure an application pool to run in classic mode, IIS processes requests for managed content by using the separate IIS and ASP.NET request-processing pipeline architecture that was introduced in IIS 6.0.

When you migrate applications from IIS 6.0 to IIS 7.0, you can initially use classic mode for applications that might not, or cannot run in integrated mode. After you have verified that these applications perform correctly, you can modify them to run in integrated mode one application pool at a time. However, the MSCOM Ops team took the opposite approach when we migrated www.microsoft.com from IIS 6.0 to IIS 7.0. We started by configuring all application pools to run in integrated mode to determine which applications would fail to work correctly. We took this approach because:

·         All applications maintain backward compatibility and run correctly in classic mode. Classic mode maintains the existing ASP.NET run-time architecture.

·         We needed to analyze applications that failed to run correctly in integrated mode to understand the root cause of any problems. For example, one of the breaking changes we encountered was that the HttpContext.Request, HttpContext.Response, HttpApplication.Request, and HttpApplication.Response properties are not available when the Application_Start method is invoked, and when the HttpModule.Init method is called for the first time during application startup. Attempts to access these properties under these conditions resulted in an HttpException that returned "Request is not available in this context" or "Response is not available in this context".

·         If a change were required to run an application, we would not have known until after we tried to run it in integrated mode.

Benefits of Classic Mode

The benefits of running applications in classic mode include:

·         Backward compatibility. ASP.NET applications run as an ISAPI just as they do in IIS 6.0.

·         Support for applications that cannot run in integrated mode (due to a breaking change or incompatibility). These applications can run in classic mode until the code is modified.

·         Ease of migration. There is no dependency on any application code changes.

Benefits of Integrated Mode

The benefits of running applications in integrated mode include:

·         ASP.NET support for all content types, including classic ASP pages and static files.

·         Availability of unified features, such as authentication, that were previously duplicated in IIS and ASP.NET.

·         ASP.NET modules that have access to all stages of the request processing pipeline.

Implementing Application Isolation

When an application pool starts in IIS 7.0, IIS reads configuration information specific to the application pool from applicationHost.config. IIS then writes this information to a temporary file that is named in the form apppoolname.config where apppoolname is the name of the application pool. Worker processes in the application pool only have access to this temporary file, and not to other application pool configuration files. This feature was introduced to help improve security and performance.

Applications in an application pool are isolated from the applications in other application pools by worker process boundaries. If an application fails, it does not affect the availability of applications that are running in other application pools. You can customize the application pools to achieve the degree of application isolation that you need. To configure application isolation, we recommend that you follow these three steps:

1.     Categorize applications according to their isolation profiles for initial deployment.

2.     Create and name the application pools by using an intuitive naming convention.

3.     Assign applications to the appropriate application pools.

You can isolate the applications that you deploy into several categories based on your assessment of their importance, their demand for server resources, or their history of instability. For example, you might categorize an application by whether it:

·         Is stable and is not subject to extremely high user demand.

·         Is expected to receive a large number of requests, thereby putting stress on the resources of the server.

·         Is mission-critical for your business and must be highly available.

·         Must be isolated from other applications and Web sites due to known or anticipated unstable behavior.

·         Requires a configuration that is different from other applications that you have categorized as standard.

The MSCOM Ops team distinguishes applications by categorizing them as either trusted code or untrusted code. An application must go through a full Software Development Life Cycle (SDLC) to be considered trusted code. SDLC methodologies provide the "what" (processes and deliverables), "how" (techniques), and "who" (roles) for every typical role in a software-development project.

Additionally, the application must undergo a verification process that is conducted by the MSCOM Debug team and a systems engineer. We consider all other applications, including many from partner organizations, to be untrusted code. The MSCOM Ops team separates these applications from each other by placing them in different application pools. Mission-critical applications or applications with known problems (such as memory leaks) may be placed in dedicated application pools.

After reaching the optimum number of application pools on a server, the luxury of isolating an application in its own application pool may no longer be an option. Therefore, we place most applications in shared application pools. In general, we place the most problematic applications in the untrusted application pool, but if an application causes other applications in the untrusted application pool to fail, we remove the application from the site until it is fixed. In addition to placing applications in application pools by categorizing them as trusted or untrusted, we also segregate them by business category, geographical region of their owners, and whether they run in integrated or classic mode.

Due to performance considerations, there is a practical limit to the number of application pools that you should create on a Web server. This number may vary depending on the number and type of applications that you run in your environment and the hardware resources that are available.

Tuning Application Pools

One of the primary goals of the MSCOM Ops team is to maintain the highest possible availability of our Web sites on the Internet. We achieve this goal in part by turning the performance of IIS 7.0 application pools. One of the most important settings that we configure when we tune our applications pools is the virtual memory limit.

We configure most of our application pools with a virtual memory limit that is based on the physical memory on the servers. We also determine the memory limit for each application pool based on several other factors. These factors include determining:

·         The proper balance between not recycling too frequently and maintaining good performance.

·         Which application pools contain applications that leak memory more rapidly than others do.

·         Which applications frequently require increased memory.

Setting the virtual memory limit instead of using a regular time limit or other recycling-related setting, however, may not be the most appropriate solution in an environment that has limited CPU or memory resources.

We also use several other application pool settings and configurations to achieve the highest possible availability of our site. For example, we:

·         Ensure that we log as much activity as possible to help in troubleshooting scenarios.

·         Use integrated instead of classic mode whenever possible.

·         Set the IIS 7.0 rapidFailProtection property (described later in Table 5) to False. This can help prevent a situation in which a poorly performing application might cause the other applications in an application pool to fail.

Note: Even if you set rapidFailProtection to False, an application pool might still fail. This can negatively impact availability and performance, and can be difficult to detect from a monitoring standpoint.

If conserving memory resources is an important consideration in your environment, you can:

·         Set the application pool properties for the idleTimeout property (described later in Table 3), thereby optimizing the amount of time that a worker process remains idle for each application pool before you remove it from memory. MSCOM Ops, however, does not use the idleTimeout property because our requirements for high availability offset our need to preserve resources.

·         Shorten the queueLength property (described later in Table 1) for the worker process in each application pool.

MSCOM Ops recommends that you only use the two preceding memory-conservation techniques in a development environment, but not on a dedicated Web server.

Configuring Application Pool Settings

This section describes application pool settings that you can configure by modifying applicationHost.config. It includes six tables that describe:

·         General settings

·         CPU settings

·         Processor model settings

·         Process orphaning settings

·         Rapid fail protection settings

·         Recycling settings

Additionally, each table lists the:

·         Name of each setting as it appears in IIS Manager.

·         Description of each setting, including the IIS 7.0 property name (in brackets) before the description.

·         Default value in IIS 7.0.

·         Settings that MSCOM Ops uses on the www.microsoft.com site.

Note: Microsoft.com Operations settings are derived from Internet traffic patterns, available hardware resources, and the applications hosted on our site. We recommend that you configure your application pool settings based on the behavior and resources in your environment. You can change these settings by using IIS Manager, the appcmd.exe command line tool, or a text editor.

Table 1 lists general application pool settings.

Table 1. IIS 7.0 Application Pool General Settings

Application Pool Setting	IIS Property and Description	Default Value	Microsoft.com Operations Setting
.NET Framework Version	[managedRuntimeVersion] Configures the application pool to load a specific version of the .NET Framework. Selecting No Managed Code causes all ASP.NET requests to fail.	v2.0	.NET Framework version 3.5 includes all the functionality of earlier versions, and introduces new features for the technologies in versions 2.0 and 3.0 and additional technologies in the form of new assemblies. To use version 3.5, install the appropriate version of .NET Framework and use product-specific guidelines.
Enable 32-bit Applications	[enable32BitAppOnWin64] If set to True for an application pool on a 64-bit operating system, the worker process(es) serving the application pool run in WOW64 (Windows on Windows64) mode. In WOW64 mode, 32-bit processes load only 32-bit applications.	False	False
Managed Pipeline Mode	[managedPipelineMode] Configures ASP.NET to run in classic mode as an ISAPI extension or in integrated mode where managed code is integrated into the request-processing pipeline.	Classic	MSCOM Ops sets to Integrated when we first migrate applications from IIS 6.0 to IIS 7.0. After testing, we move applications that fail to run correctly to an application pool that is configured as Classic.
Queue Length	[queueLength] Maximum number of requests that Http.sys queues for the application pool. When the queue is full, new requests receive a 503 “Service Unavailable” response.	1000	9000
Start Automatically	[autoStart] If True, the application pool starts on creation or when IIS starts. Starting an application pool sets this property to True. Stopping an application sets this property to False.	True	True

 

Table 2 lists application pool CPU settings.

Table 2. IIS 7.0 Application Pool CPU Settings

Application Pool Setting	IIS Property and Description	Default Value	Microsoft.com Operations Setting
Limit	[limit] Configures the maximum percentage of CPU time (in 1/1000ths of a percent) that the worker processes in an application pool are allowed to consume over a period of time as indicated by the Limit Interval setting (resetInterval property). If the limit set by Limit (limit property) is exceeded, the event is written to the event log and an optional set of events can be triggered or determined by the Limit Action setting (action property). Setting the value of Limit to 0 disables limiting the worker processes to a percentage of CPU time.	0	0
Limit Action	[action] If set to NoAction, an event log entry is generated. If set to KillW3WP, the application pool is shut down for the duration of the reset interval and an event log entry is generated.	No Action	No Action
Limit Interval (minutes)	[resetInterval] Specifies the reset period (in minutes) for CPU monitoring and throttling limits on the application pool. When the number of minutes elapsed since the last process accounting reset equals the number specified by this property, IIS resets the CPU timers for both the logging and limit intervals. Setting the value of Limit Interval to 0 disables CPU monitoring.	5	5
Processor Affinity Enabled	[smpAffinitized] If True, Processor Affinity Enabled forces the worker process(es) serving this application pool to run on specific CPUs. This enables sufficient use of CPU caches on multiprocessor servers.	False	False
Processor Affinity Mask	[smpProcessorAffinityMask] Hexadecimal mask that forces the worker process(es) for this application pool to run on a specific CPU. If processor affinity is enabled, a value of 0 causes an error condition.	4294967295	4294967295

 

Table 3 lists general application processor model settings.

Table 3. IIS 7.0 Application Pool Processor Model Settings

Application Pool Setting	IIS Property and Description	Default Value	Microsoft.com Operations Setting
Identity	[identityType] Configures the application pool to run as a built-in account, such as Network Service (recommended), Local Service, or as a specific user identity.	NetworkService	NetworkService
Idle Timeout (minutes)	[idleTimeout] Amount of time (in minutes) a worker process remains idle before it shuts down. A worker process is idle if it is not processing requests and no new requests are received.	20	0 MSCOM Ops does not use for production servers because we need to maintain high availability as opposed to preserving server resources.”
Load User Profile	[loadUserProfile] Specifies whether IIS loads the user profile for an application pool identity. When set to True, IIS loads the user profile for the application pool identity. Set to False when you require IIS 6.0 behavior.	False	False
Maximum Worker Processes	[maxProcesses] Maximum number of worker processes permitted to service requests for the application pool. If this number is greater than 1, the application pool is called a Web garden.	1	1
Ping Enabled	[pingEnabled] If True, the worker process(es) serving this application pool are pinged periodically to ensure that they are still responsive. This process is called health monitoring.	True	True
Ping Maximum Response Time (seconds)	[pingResponseTime] Maximum time (in seconds) that a worker process is given to respond to a health monitoring ping. If the worker process does not respond, it is terminated.	90	10
Ping Period (seconds)	[pingInterval] Period of time (in seconds) between health monitoring pings sent to the worker process(es) serving this application pool.	30	10
Shutdown Time Limit (seconds)	[shutdownTimeLimit] Period of time (in seconds) a worker process is given to finish processing requests and shut down. If the worker process exceeds the shutdown time limit, it is terminated.	90	90
Startup Time Limit (seconds)	[startupTimeLimit] Period of time (in seconds) a worker process is given to start up and initialize. If the worker process initialization exceeds the startup time limit, it is terminated.	90	90

 

Table 4 lists application pool process orphaning settings.

Table 4. IIS 7.0 Application Pool Process Orphaning Settings

Application Pool Setting	IIS Property and Description	Default Value	Microsoft.com Operations Setting
Enabled	[orphanWorkerProcess] If True, an unresponsive worker process is abandoned (orphaned) instead of terminated. This feature can be used to debug a worker process failure.	False	False
Executable	[orphanActionExe] Executable to run when a worker process is abandoned (orphaned). For example, “C:\dbgtools\ntsd.exe would invoke NTSD to debug a worker process failure.
Executable Parameters	[orphanActionParams] Parameters for the executable that is run when a worker process is abandoned (orphaned). For example, -g –p %1% is appropriate if the NTSD is the executable invoked for debugging worker process failures.

 

Table 5 lists application pool rapid fail protection settings.

Table 5. IIS 7.0 Application Pool Rapid Fail Protection Settings

Application Pool Setting	IIS Property and Description	Default Value	Microsoft.com Operations Setting
Service Unavailable” Response Type	[loadBalancerCapabilities] If set to HttpLevel and the application pool is stopped, Http.sys returns an HTTP 503 error. If set to TcpLevel, Http.sys resets the connection. This is useful if the load balancer recognizes one of the response types and subsequently redirects it.	HttpLevel	Select a setting that meets the requirements of your load balancer.
Enabled	[rapidFailProtection] If True, the application pool is shut down if there are a specified number of worker process failures (Maximum Failures) within a specified period (Failure Interval). By default, an application pool is shut down if there are five failures in a five minute period.	True	False in a production environment. True only in a testing environment.
Failure Interval (minutes)	[rapidFrailProtectionInterval] The time interval (in minutes) during which the specified number of worker process failures (Maximum Failures) must occur before the application pool is shut down by Rapid Fail Protection.	5	Refer to rapidFailProtection (Enabled) in this table.
Maximum Failures	[rapidFailProtectionMaxCrashes] Maximum number of worker process failures permitted before the application pool is shut down by Rapid Fail Protection.	5	Refer to rapidFailProtection (Enabled) in this table.
Shutdown Executable	[autoShutdownExe] Executable to run when an application pool is shut down by Rapid Fail Protection. This can be used to configure a load balancer to redirect traffic for this application to another server.
Shutdown Executable Parameters	[autoShutdownParams] Parameters for the executable to run when an application pool is shut down by Rapid Fail Protection.

 

Table 6 lists application pool recycling settings.

Table 6. IIS 7.0 Application Pool Recycling Settings

Application Pool Setting	IIS Property and Description	Default Value	Microsoft.com Operations Setting
Disable Overlapped Recycle	[disallowOverlappingRotation] If True, when the application pool recycles, the existing worker process exits before another worker process is created. Set to True if the worker process loads an application that does not support multiple instances.	False	False
Disable Recycling for Configuration Changes	[disallowRoationOnConfigChange] If True, the application pool does not recycle when its configuration is changed.	False	False
Generate Recycle Event Log Entry	[logEventOnRecycle] Generates an event log entry for each occurrence of the specified recycling events.	See specific recycle configuration options in the following eight settings.
Application Pool Configuration Changed	[ConfigChange] If True, an event log entry is generated when an application pool recycles due to a change in its configuration.	False	True
Isapi Reported Unhealthy	[IsapiUnhealthy] If True, an event log entry is generated when an application pool recycles because an ISAPI extension has reported itself as unhealthy.	False	True
Manual Recycle	[OnDemand] If True, an event log entry is generated when the application pool has been manually recycled.	False	True
Private Memory Limit Exceeded	[PrivateMemory] If True, an event log entry is generated when the application pool recycles after exceeding its private memory limit.	True	True
Regular Time Interval	[Time] If True, an event log entry is generated when the application pool recycles at its scheduled interval.	True	True
Request Limit Exceeded	[Requests] If True, an event log entry is generated when the application pool recycles after exceeding its request limit.	False	True
Specific Time	[Schedule] If True, an event log entry is generated when the application pool recycles at a scheduled time.	False	True
Virtual Memory Limit Exceeded	[Memory] If True, an event log entry is generated when the application pool recycles after exceeding its virtual memory limit.	True	True
Private Memory Limit (KB)	[privateMemory] Maximum amount of private memory (in KB) a worker process can consume before causing the application pool to recycle. A value of 0 means there is no limit.	0	0
Regular Time Interval (minutes)	[time] Period of time (in minutes) after which an application pool recycles. A value of 0 means the application pool does not recycle at a regular interval.	1740	0.
Request Limit	[requests] Maximum number of requests an application pool can process before it is recycled. A value of 0 means the application pool can process an unlimited number of requests.	0	0
Specific Times	[schedule] A set of specific local times, in 24 hour format, when the application pool is recycled.	TimeSpan[ ] Array	.
Virtual Memory Limit (KB)	[memory] Maximum amount of virtual memory (in KB) a worker process can consume before causing the application pool to recycle. A value of 0 means there is no limit.	0	MSCOM Ops sets a value based on the physical memory (in KB) instead of using a regular time interval.

 

For more information about how to use the attributes listed in Tables 1 through 6, see "IIS 7.0: applicationPools Section (IIS Settings Schema)".

Configuration Changes that Force Application Pools to Recycle

IIS 7.0 is designed to minimize the recycling of application pools and worker processes when you make modifications to applicationHost.config. The Web Application Stress (WAS) tool relies upon the granular change notification from nativerd.dll to regenerate application pool configuration files for only those applications that are affected. 

However, there are some changes to configuration that force WAS to recycle an application pool. For example, WAS recycles an application pool if you change the configuration of any of the following:

·         Restart parameters (for example, restart time, number of requests, and scheduled memory)

·         idleTimeout property

·         pingInterval property

·         Startup and shutdown time limit

·         Orphan action

·         CLR version

·         Pipeline mode

·         A 32 to 64 bit worker process

·         Job objects (for example, CPU limit)

·         CPU affinity

·         Worker process identity

Schema changes and global changes that affect all sites trigger a wholesale reset of all application pools. This may be as seemingly innocuous as changing a single setting in the <system.webServer> section in applicationHost.config. As a result, all application pool configuration files must be updated. Additionally, even though some changes that update the application pool configuration may not recycle a worker process, the granular change code does not extend to ASP.NET. Therefore, it is possible that the managed application domain may shut down.

When you make a configuration change in applicationHost.config, and if a granular listener (such as WAS) is notified, nativerd.dll (which reads native code configuration) supplies a configuration path that depends on the type of change that you make. For example, nativerd.dll evaluates:

·         A change in the global scope (such as <location path=””> in MACHINE/WEBROOT/APPHOST) that is not in the <sites>, <customMetadata>, or <configHistory> sections, as a change in MACHINE/WEBROOT/APPHOST.

·         A change in a <site> element in the <sites> section that is not in an <application> element as a change to the site path.

·         A change in an <application> element as a change to the application path.

·         A change in a non-global <location> tag in MACHINE/WEBROOT/APPHOST as a change to the configuration path for that location path.

Nativerd.dll supplies the union of all configuration paths where changes are discovered by WAS. Some optimizations exist that allow Nativerd.dll to bypass the examination of any path whose parent path is already considered to have been changed.

Although changes to MACHINE/WEBROOT/APPHOST force all worker processes to recycle, changes to a configuration path that is unambiguously an application path only cause the worker process containing that application to recycle.

How Microsoft Engineering Operations Configures Application Pools

This section discusses how MSCOM Ops configures application pools. It illustrates how we define application pool settings in applicationHost.config, and provides examples that demonstrate how you can create similar configurations by using the appcmd.exe command line tool or IIS Manager.

Note: The settings listed in this article are based on how the MSCOM Engineering Operations team tunes application pools in our environment. They are based on the applications, code, and hardware that our servers run on, and you should not use them as defaults. We recommend that you tune the recycling limits on your servers based on the behavior of the applications that run in your environment.

For security reasons, the sample names of forests, domains, internal resources, organizations, and internally developed security file names that are used in this article do not represent real resource names used within Microsoft and are for illustration purposes only.

Defining Application Pool Settings in applicationHost.config

The following examples illustrate how MSCOM Ops:

·         Defines global settings for application pools.

·         Configures request processing modes for application pools.

·         Configures sites and assigns them to application pools.

The following example illustrates how MSCOM Ops defines global settings for the <applicationPools> section in the system.applicationHost section group under <configSections>:

    <configSections>

        <sectionGroup name="system.applicationHost">

            <section name="applicationPools" allowDefinition="AppHostOnly" overrideModeDefault="Deny" />

           

        </sectionGroup>

 

The following example illustrates how MSCOM Ops defines application pools in either classic or integrated mode. It also shows how recycling can be configured for individual application pools. In this example, the recycling is based on virtual memory limits:

            <applicationPools>

                  <add name="DefaultAppPool" managedPipelineMode="Integrated" />

                  <add name="SampleAppPool01" managedPipelineMode="Integrated">

                        <recycling>

                              <periodicRestart memory="3072000">

                                    <schedule>

                                          <clear />

                                    </schedule>

                              </periodicRestart>

                        </recycling>

                  </add>

                  <add name="SampleAppPool02" managedPipelineMode="Classic">

                        <recycling>

                              <periodicRestart memory="2048000">

                                    <schedule>

                                          <clear />

                                    </schedule>

                              </periodicRestart>

                        </recycling>

            </applicationPools>

 

Note: If you want to set recycling based on private bytes, use privateMemory when you set <periodicRestart>. Other options include regular time intervals, fixed number of requests, and specific times. These settings are described in Table 6.

The following example illustrates how we configure individual sites and assign them to application pools:

        <sites>

            <site name="www.samplebussite.com" id="1">

               

                <application path="/SampleSite01" applicationPool="SampleAppPool01">

                    <virtualDirectory path="/" physicalPath="drive:\http\siteresources\SampleSite01" />

                </application>

                <application path="/SampleSite02" applicationPool="SampleAppPool01">

                    <virtualDirectory path="/" physicalPath="drive:\http\siteresources\SampleSite02" />

                </application>

               

            </site>

            <siteDefaults>

                <logFile logFormat="W3C" directory="%SystemDrive%\inetpub\logs\LogFiles" />

                <traceFailedRequestsLogging directory="%SystemDrive%\inetpub\logs\FailedReqLogFiles" />

                <limits maxConnections="4294967295" />

            </siteDefaults>

            <applicationDefaults applicationPool="SampleAppPool01" />

            <virtualDirectoryDefaults allowSubDirConfig="true" />

        </sites>

 

Creating and Configuring Application Pools

You can create and configure application pools by:

·         Manually editing applicationHost.config.

·         Using the appcmd.exe command line tool.

·         Using IIS Manager.

This section contains examples that demonstrate how to create and configure application pools by using appcmd.exe and IIS Manager. The examples demonstrate how to:

·         List all application pools on the server.

·         Add an application pool and specify the request-processing mode.

·         Change the request-processing mode of an application pool.

·         Configure an application pool to recycle when it reaches a virtual memory limit.

·         Create a site.

·         Add a site to an application pool.

When you install IIS 7.0, the DefaultAppPool application pool is automatically created. DefaultAppPool and any new application pools you create are configured in integrated mode and use .NET Framework 2.0 by default.

If you configure an application pool in classic mode and then verify that all of its applications are performing correctly, you can change the request-processing mode to integrated. You can then verify how well the applications perform in integrated mode before you place them online.

By default, IIS 7.0 recycles an application every 1,740 minutes (29 hours) whether it is necessary or not. However, MSCOM Ops overrides this setting by configuring some application pools to recycle when it reaches a specific virtual memory limit. To configure an application pool to recycle when it reaches a memory limit, you specify the amount of virtual or private memory in kilobytes.

You must create a site before you can add it to an application pool. It is assumed that you have created the C:\inetpub\SampleSite01 folder for the site before you execute the site-related commands in the following examples.

Using appcmd.exe to Create and Configure Application Pools

The appcmd.exe command line tool is installed in the %windir%\system32\inetsrv folder by default. It is assumed that you have used the command prompt to navigate to this folder, or that you have added a reference to this folder to the Path environment variable, prior to using the following examples.

For more information about how to use appcmd.exe, see “Getting Started with AppCmd.exe”.

To view a list of application pools by using appcmd.exe

At the command prompt, type

appcmd list apppools

 

and press Enter.

To create an application pool by using appcmd.exe

To add an application pool to a Web server by using default settings, use the following syntax:

At the command prompt, type

appcmd add apppool /name:SampleAppPool01

 

where SampleAppPool01 is the name of the application pool, and press Enter.

By default, IIS 7.0 adds an application pool that runs in integrated mode. If you want to add an application pool that runs in classic mode, you can specify the managed request-processing mode by using the /managedPipelineMode attribute.

To add an application pool to a Web server that runs in classic mode, use the following syntax:

At the command prompt, type

appcmd add apppool /name:SampleAppPool02 /managedPipelineMode:Classic

 

where SampleAppPool02 is the name of the application pool, and press Enter.

To change the request-processing mode of an application pool by using appcmd.exe

At the command prompt, type

appcmd set apppool /apppool.name:SampleAppPool02 /managedPipelineMode:Integrated

 

where SampleAppPool02 is the name of the application pool, and press Enter.

To specify a virtual memory limit for an application pool by using appcmd.exe

At the command prompt, type

appcmd set config /section:applicationPools / [name='SampleAppPool01'].recycling.periodicRestart.memory:2048000

 

where SampleAppPool01 is the name of the application pool, and press Enter.

To create a site by using appcmd.exe

At the command prompt, type

appcmd add site /name:SampleSite01 /physicalPath:C:\inetpub\SampleSite01

 

where SampleSite01 is the name of the application pool, and press Enter.

To assign a site to an application pool by using appcmd.exe

At the command prompt, type

appcmd set app "SampleSite01/" /applicationPool:SampleAppPool01

 

and press Enter.

Using IIS Manager to Create and Configure Application Pools

Use the following steps to open IIS Manager.

To open IIS Manager from the Start menu

1.     Click Start, and then click All Programs.

2.     Click Administrative Tools, and then click Internet Information Services (IIS) Manager.

To open IIS Manager from the Search box

1.     Click Start.

2.     In the Start Search box, type inetmgr and press ENTER.

For more information about how to use IIS Manager, see “Getting Started with IIS Manager”.

To view a list of application pools by using IIS Manager

1.     Open IIS Manager.

2.     In the Connections pane, click Application Pools in the tree.

To create an application pool by using IIS Manager

1.     Open IIS Manager.

2.     In the Connections pane, expand the server node and click Application Pools.

3.     On the Application Pools page, in the Actions pane, click Add Application Pool.

4.     On the Add Application Pool dialog box, type SampleAppPool01 in the Name box where SampleAppPool01 is the name of the application pool.

5.     From the .NET Framework version list, select the version of the .NET Framework required by your managed applications, modules, and handlers. Or select No Managed Code if the applications that you run in this application pool do not require the .NET Framework.

6.     From the Managed pipeline mode list, select Classic.

7.     Select Start application pool immediately to start the application pool whenever the WWW service is started. By default, this is selected.

8.     Click OK.

To change the request-processing mode of an application pool by using IIS Manager

1.     Open IIS Manager.

2.     In the Connections pane, expand the server node and click Application Pools.

3.     On the Application Pools page, click to select the SampleAppPool01 application pool from the list where SampleAppPool01 is the name of the application pool.

4.     In the Actions pane, click Basic Settings.

5.     From the Managed pipeline mode list, select Integrated.

6.     Click OK.

To specify a virtual memory limit for an application pool by using IIS Manager

1.     Open IIS Manager.

2.     In the Connections pane, expand the server node and click Application Pools.

3.     On the Application Pools page, select an application pool, and then click Recycling in the Actions pane.

4.     Select Virtual memory usage (in KB), and in the corresponding box type a memory value at which you want the application pool to recycle.

5.     Click Next, optionally select the events that should be logged when an application pool recycles, and then click Finish.

To create a site by using IIS Manager

1.     Open IIS Manager.

2.     In the Connections pane, expand the server node and click Web Sites.

3.     On the Web Sites page, in the Actions pane, click Add Web Site.

4.     On the Add Web Site dialog box, type SampleSite01 in the Web site name box where SampleSite01 is the name of the site.

5.     Browse to select C:\inetpub\SampleSite01 in the Physical path box.

6.     From the Managed pipeline mode list, select Classic.

7.     Optionally, specify Binding parameters.

8.     Click OK.

To assign a site to an application pool by using IIS Manager

1.     Open IIS Manager.

2.     In the Connections pane, expand the server node and click Web Sites.

3.     On the Web Sites page, select SampleSite01.

4.     On the Actions pane, click Web Site Defaults.

5.     On the Web Site Defaults dialog box, click the Application Pool browse button.

6.     On the Select Application Pool dialog box, select SampleAppPool01 from the Application Pool drop-down list.

7.     Click OK.

Summary

In this article, we described how the Microsoft Engineering Operations team uses both integrated and classic request processing to manage application pools in IIS 7.0. We also discussed how we leverage the benefits of integrated mode, described the configuration settings that we use to tune application pools, and explained which configuration changes result in application pool recycling. Additionally, we provided examples that demonstrate how you can configure application pools by using appcmd.exe command line tool and IIS Manager.

Additional References

Customizing IIS 7.0 Roles and Modules

Delegating Configuration in IIS 7.0