IIS App Pools - Stop/Start vs Recycle

Question

I\'ve noticed that on one of my production web apps, when I manually recycle an app pool, the recycled worker process can take upwards of 60+ seconds to actually be completely d

Answer 1

According to this link,

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.

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.