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
a) Because of Overlapped Recycling. There is a time period that the "old" process waits for the new one to start.
b) No. As far as I know.
A recycle if I recall correctly allows all existing requests to finish then it will recycle the application pool. A stop simply ends it at the exact instant that you stop it.
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.