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.