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

我注意到，在我的一个生产web应用程序上，当我手动回收一个应用程序池时，根据任务管理器中的观察，回收的工作进程实际上需要60多秒才能完全销毁。但是，如果我完全停止应用程序池，工作进程几乎会在1-2秒内立即消失

因此，我的问题有两个：

a） 当应用程序池被回收而不是停止时，为什么要花这么长的时间来破坏进程（更重要的是，释放它使用/锁定的资源）；及

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

---

编辑：
为了澄清这一点，在我回收或停止应用程序池之前，我会停止将流量发送到相关服务器（服务器位于负载平衡集群中，我会从负载平衡器中删除服务器）。因此，从理论上讲，在我对应用程序池进行任何操作时，不应该有任何请求进入网站

---

编辑部分双份：
在阅读了Igal的链接后，我似乎很清楚发生了什么。当我回收应用程序池时，新进程将启动，但由于根本没有流量，它不会将新进程注册为正常运行，因此直到超时（即90秒）时才会关闭旧进程

---

有了这些知识，我很清楚“回收”功能专门用于实时服务器的中游，而且由于我事先手动排放流量，因此我应该使用停止/启动来代替。

如果我正确调用，则允许完成所有现有请求，然后它将回收应用程序池。停止只是在你停止它的那一刻结束它。

A）因为。“旧”进程等待新进程启动有一段时间

b） 没有。据我所知。

根据

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

如果工作进程未在指定的时间内退出 通过processModel中的shutdownTimeLimit配置属性 每个应用程序池定义的元素（默认值：90秒）为 将强制终止它（如果本机调试器 附件）

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

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

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

---

停止

正常停止此应用程序池的所有现有工作进程

不允许为此应用程序池启动新的工作进程

回收利用

正常停止此应用程序池的所有现有工作进程

允许为此应用程序池启动新的工作进程

重置应用程序状态和缓存

---

注：两者的第1点完全相同。第3点不适用于停止，因为进程已结束，因此状态显然已结束。

@igal Hi，假设服务器为John（inProc）进行了会话。现在让我们假设管理员进行了

回收

。现在发生了重叠Recycling。所有请求都已完成。新的过程开始了。john现在是否具有相同的会话ID？（重新启动无法确定是否保存。问题是回收）。@RoyiNamir嗨。回收不会有帮助。会话ID和会话数据在回收后丢失。这是一个非常旧的答案，带有一些向上投票，但我猜这不是一个准确的答案。请检查我下面的回答，并给你一些思考。