我注意到，在我的一个生产网络应用程序中，当我手动回收应用程序池时，基于在任务管理器中观察，回收的工作进程可能需要超过60秒以实际完全销毁。但是，如果我完全停止应用程序池，则工作进程几乎立即消失 - 在1-2秒内。
所以，我的问题是双重的：
a）当应用程序池被回收而不是停止时，为什么要花费这么长时间来销毁进程（更有意义的是，释放由它使用/锁定的资源）;和
b）假设我已停止将流量定向到服务器，是否有任何理由不停止/启动而不是回收？
修改
为了澄清，在我回收或停止应用程序池之前，我阻止将流量发送到有问题的服务器（服务器位于负载平衡群集中，我从负载均衡器中删除服务器）。因此，从理论上讲，当我对应用程序池做任何事情时，不应该有任何请求进入网站。
编辑零件Deux：
在阅读了Igal的链接后，对我来说似乎很明显发生了什么。当我回收应用程序池时，新进程已启动，但由于根本没有流量，因此它没有将新进程注册为正常运行，因此在超时之前它不会关闭旧进程（即90秒）。
有了这些知识，我很清楚“回收”功能专门用于在实时服务器的中游使用，而且由于我事先手动耗尽流量，所以我应该使用停止/启动。
答案 0 :(得分：26)
a）因为Overlapped Recycling。有一段时间，“旧”进程等待新的进程开始。
b）不，据我所知。
答案 1 :(得分：13)
如果我回忆正确，回收允许所有现有请求完成，那么它将回收应用程序池。停止只是在您停止它的确切时刻结束它。
答案 2 :(得分：0)
根据this link，
停止 –通过停止应用程序池，您正在指示服务于该应用程序池的所有IIS工作进程关闭， 并防止启动任何其他辅助进程，直到 应用程序池再次启动。 这将启动一个优美的环境 关闭工作进程，并尝试每个工作进程 清空所有请求，然后退出。
如果工作进程在指定的时间内没有退出 通过processModel中的shutdownTimeLimit配置属性 每个应用程序池的定义的元素（默认值：90秒），WAS 将强制终止它（如果本机调试器不会发生这种情况 附件）。
因此，停止应用程序池是一种破坏性操作， 导致卸载ASP.NET应用程序域，FastCGI子进程， 以及任何进程内应用程序状态的丢失。
回收 –回收应用程序池会使该应用程序池中所有当前正在运行的IIS工作进程正常运行 关闭，但与停止池不同，新的IIS工作进程可以 按需启动以处理后续请求。
回收应用程序池是导致重置的好方法 应用程序状态和IIS工作程序缓存的任何配置 不会自动刷新的进程（主要是全局的 注册表项），而不会影响服务器的运行。这个 使回收应用程序池成为替代 在大多数情况下为IISRESET。
答案 3 :(得分：0)
停止
回收
注意： 两者的第 1 点完全相同。第 3 点不适用于停止，因为过程消失了，所以状态显然消失了。