Starting, stopping and recycling IIS 7.0 Web sites and application pools

As many of you know, IIS 7.0 provides the ability to start and stop Web sites, and application pools.  However, since previous releases, there has been much confusion as to what exactly happens when you do so. This post should clarify this and provide you with the tools you need to execute the tasks correctly.

1) Web sites

Stopping - by stopping a Web site, you indicate that the Web site no longer listens for requests on all of its bindings.  This prevents any subsequent requests from being received by your applications in the Web site; new connections to your Web site will fail as if it didnt exist.  However, worker processes serving your web site, applications loaded in those worker processes, and their state remains unaffected.

This makes stopping a Web site a great way to temporarily prevent the Web site from receiving additional requests, without unloading any application state. By starting the Web site, you can very quickly resume request processing.

Starting - by starting a stopped Web site, you instruct it to begin listening for requests again.

Pausing - this doesnt exist anymore. In IIS 7.0, pausing a Web site is the same as stopping it.

Both starting and stopping a Web site does not require writing to configuration.  Instead, these actions send control signals to the W3SVC service. This means that when the server is rebooted, or the W3SVC service is restarted manually or through IISRESET, the sites automatically restart (see next note).

That is, unless the Web site is marked in configuration to not restart automatically.  This is controlled by the serverAutoStart configuration property on the site element.

Final note: when you start or stop the Web site in IIS Manager, it also sets the serverAutoStart property to the corresponding state. When you start or stop the Web site using AppCmd however (or code), you have to manually toggle the serverAutoStart property if you so desire. With that in mind, to stop a Web site and leave it stopped regardless of W3SVC service restarts:

> %windir%\system32\inetsrv\AppCmd Stop Site MySite
> %windir%\system32\inetsrv\AppCmd Set Site MySite /serverAutoStart:false

Likewise, to start it and leave it started:

> %windir%\system32\inetsrv\AppCmd Start Site MySite
> %windir%\system32\inetsrv\AppCmd Set Site MySite /serverAutoStart:true

2) Application pools

Stopping - by stopping an application pool, you are instructing all IIS worker processes serving this application pool to shut down, and prevent any additional worker processes from being started until the application pool is started again. This initiates a graceful shutdown of the worker processes, with each worker process attempting to drain all of it's requests and then exit.

If a worker process does not exit within the amount of time specified by the shutdownTimeLimit configuration property in the processModel element of each application pool's definition (default: 90 sec), WAS will forcefully terminate it (this doesnt happen if a native debugger is attached).

Therefore, stopping an application pool is a disruptive action that causes unload of ASP.NET application domains, FastCGI child processes, and loss of any in-process application state.

After the application pool is stopped, all subsequent requests to all Web applications in the application pool will return 503 Service Unavailable errors untill the application pool is started. The application pool may become automaticaly stopped if the Rapid Failure Protection feature is activated. For more information on troubleshooting this condition, see my earlier post: Troubleshooting 503 / "service unavailable" errors.

Starting - starting an application pool enables IIS worker processes to be created to serve requests in that pool.

Recycling - recycling an application pool causes all currently running IIS worker processes in that application pool to be gracefully shutdown, but unlike stopping the pool, new IIS worker processes can be started on demand to handle subsequent requests. 

Recycling an application pool is a good way to cause the reset of application state and any configuration cached by the IIS worker processes that does not get automatically refreshed (mostly global registry keys), without disrupting the operation of the server. This makes recycling the application pool a great alternative to an IISRESET in most cases.

(NOTE: You DO NOT need to recycle IIS 7.0 application pools or perform an IISRESET when you change configuration.  All IIS 7.0 features automatically pick up configuration changes (and some changes may trigger IIS worker process to recycle automatically, such as a change to the globalModules configuration section). However, recycling may be necessary when you change registry keys.)

Recycling an application pool SHOULD NOT cause any request errors.  The only time you may see errors is if your applications require a long warmup time to restore their state and this causes requests to either time out, or your server to become overloaded and reject requests. This can typically be mitigated by adjusting application pool queue sizes and queue timeouts.

Just like starting and stopping sites, starting and stopping application pools does not change configuration, but instead sends a control signal to the WAS service. Therefore, when the server is rebooted or the service restarts, application pools will typically also start again unless they are configured not to do this through the autoStart configuration property. 

To stop an application pool and leave it stopped:

> %windir%\system32\inetsrv\AppCmd Stop Apppool MyAppPool
> %windir%\system32\inetsrv\AppCmd Set Apppool MyAppPool /autoStart:false

Likewise, to start it and leave it started:

> %windir%\system32\inetsrv\AppCmd Start Apppool MyAppPool
> %windir%\system32\inetsrv\AppCmd Set Apppool MyAppPool /autoStart:true

This should help clarify things. As always, shout if you got more questions.

Thanks,

Mike