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 destroyed, based on watching it in Task Manager. However, if I stop the app pool completely, the worker process goes away nearly instantaneously - within 1-2 seconds.
So, my question is two-fold:
a) Why does it take so long to destroy the process (and more meaningfully, release the resources used/locked by it) when the app pool is recycled instead of stopped; and
b) Assuming that I've stopped traffic from being directed to the server, is there any reason NOT to stop/start instead of recycle?
Edit:
To clarify, before I either recycle or stop the app pool, I stop traffic from being sent to the server in question (the server is in a load balanced cluster, and I remove the server from the load balancer). So, in theory, there should be no requests coming to the web site at the time I am doing anything to the app pool.
Edit Part Deux:
After reading Igal's link, it seems pretty obvious to me what is happening. When I recycle the app pool, the new process is started, but since there is no traffic at all, it isn't registering the new process as functioning, so it doesn't shut down the old one until the timeout (which is 90 seconds).
With that knowledge, it's clear to me that the "Recycle" functionality is specifically intended to be used midstream on a live server, and since I am manually draining traffic beforehand, I should use stop/start instead.
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.
来源：https://stackoverflow.com/questions/391878/iis-app-pools-stop-start-vs-recycle