IIS应用程序池 - 停止/启动与回收

Question

我注意到，在我的一个生产网络应用程序中，当我手动回收应用程序池时，基于在任务管理器中观察，回收的工作进程可能需要超过60秒以实际完全销毁。但是，如果我完全停止应用程序池，则工作进程几乎立即消失 - 在1-2秒内。

所以，我的问题是双重的：

a）当应用程序池被回收而不是停止时，为什么要花费这么长时间来销毁进程（更有意义的是，释放由它使用/锁定的资源）;和

b）假设我已停止将流量定向到服务器，是否有任何理由不停止/启动而不是回收？

---

修改
 为了澄清，在我回收或停止应用程序池之前，我阻止将流量发送到有问题的服务器（服务器位于负载平衡群集中，我从负载均衡器中删除服务器）。因此，从理论上讲，当我对应用程序池做任何事情时，不应该有任何请求进入网站。

---

编辑零件Deux：
 在阅读了Igal的链接后，对我来说似乎很明显发生了什么。当我回收应用程序池时，新进程已启动，但由于根本没有流量，因此它没有将新进程注册为正常运行，因此在超时之前它不会关闭旧进程（即90秒）。

有了这些知识，我很清楚“回收”功能专门用于在实时服务器的中游使用，而且由于我事先手动耗尽流量，所以我应该使用停止/启动。

Answer 1

a）因为Overlapped Recycling。有一段时间，“旧”进程等待新的进程开始。

b）不，据我所知。

Answer 2

如果我回忆正确，回收允许所有现有请求完成，那么它将回收应用程序池。停止只是在您停止它的确切时刻结束它。

Answer 3

根据this link，

  

停止 –通过停止应用程序池，您正在指示服务于该应用程序池的所有IIS工作进程关闭，   并防止启动任何其他辅助进程，直到   应用程序池再次启动。 这将启动一个优美的环境   关闭工作进程，并尝试每个工作进程   清空所有请求，然后退出。

     

如果工作进程在指定的时间内没有退出   通过processModel中的shutdownTimeLimit配置属性   每个应用程序池的定义的元素（默认值：90秒），WAS   将强制终止它（如果本机调试器不会发生这种情况   附件）。

     

因此，停止应用程序池是一种破坏性操作，   导致卸载ASP.NET应用程序域，FastCGI子进程，   以及任何进程内应用程序状态的丢失。

     

回收 –回收应用程序池会使该应用程序池中所有当前正在运行的IIS工作进程正常运行   关闭，但与停止池不同，新的IIS工作进程可以   按需启动以处理后续请求。

     

回收应用程序池是导致重置的好方法   应用程序状态和IIS工作程序缓存的任何配置   不会自动刷新的进程（主要是全局的   注册表项），而不会影响服务器的运行。这个   使回收应用程序池成为替代   在大多数情况下为IISRESET。

Answer 4

停止

1. 优雅地停止此应用程序池的所有现有工作进程。
2. 不要允许为此应用程序池启动新的工作进程。

回收

1. 优雅地停止此应用程序池的所有现有工作进程。
2. 允许为此应用程序池启动新的工作进程。
3. 重置应用程序状态和缓存

注意： 两者的第 1 点完全相同。第 3 点不适用于停止，因为过程消失了，所以状态显然消失了。