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

Question

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

所以,我的问题是双重的:

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

b)假设我已经阻止流量被定向到服务器,是否有任何理由不停止/启动而不是回收？

---

编辑:
为了澄清,在我回收或停止应用程序池之前,我阻止流量被发送到有问题的服务器(服务器在负载平衡群集中,我从负载均衡器中删除服务器).因此,理论上,在我对应用程序池执行任何操作时,不应该向网站发出请求.

---

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

有了这些知识,我很清楚"回收"功能专门用于在实时服务器的中游使用,并且因为我事先手动排出流量,所以我应该使用停止/启动.

Answer 1

a)由于重叠回收.有一段时间"旧"进程等待新进程开始.

b)不,据我所知.

Answer 2

如果我没记错,回收可以让所有现有的请求完成,然后它将回收应用程序池.停止只是在您停止它的确切时刻结束它.

Answer 3

根据这个链接，

停止– 通过停止应用程序池，您将指示为该应用程序池提供服务的所有 IIS 工作进程关闭，并阻止任何其他工作进程启动，直到应用程序池再次启动。这将启动工作进程的正常关闭，每个工作进程都试图耗尽它的所有请求，然后退出。

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

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

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

回收应用程序池是一种很好的方法，可以在不中断服务器运行的情况下重置应用程序状态和 IIS 工作进程缓存的任何配置，这些配置不会自动刷新（主要是全局注册表项）。在大多数情况下，这使得回收应用程序池成为 IISRESET 的绝佳替代方案。