编辑 Web.config 文件是否会触发重叠回收或应用程序池的启动+停止？答案

【问题标题】：Does editing a Web.config file trigger an overlapping recycle or a start+stop of the application pool?编辑 Web.config 文件是否会触发重叠回收或应用程序池的启动+停止？
【发布时间】：2015-02-26 14:56:36
【问题描述】：

我为我的 ASP.NET MVC 站点配置了 Overlapping Recycling。

据我了解 (from this SO question)，如果我回收应用程序池，这将启动一个新的 w3wp.exe 进程以承担正在回收的进程的负载，并且仅在新进程初始化并承担负载，是否会关闭旧进程。如果我停止/启动应用程序池，它会立即终止，而不会让进程正常退出或让替换进程先启动。

问题：当我编辑我的 Web.config 文件时，它会重新启动关联的 IIS 应用程序池。这会触发良好的重叠回收行为，还是残酷的停止/启动行为？

我正在尝试决定是否需要将服务器从负载平衡的场中取出并停止服务器流量以编辑配置设置。

【问题讨论】：

我不确定，但 web.config 更改是在 ASP.Net 级别处理的。它具有监视该文件和几个目录的文件监视器。并且 Overlappign Recycling 是 IIS 的东西，所以对我来说它会做残酷的 stop\start。

标签： asp.net-mvc iis-7.5 web-farm

【解决方案1】：

我决定使用科学。我在负载测试工具下对我的服务器进行了一项实验，我在其中反复编辑并保存了我的 Web.config 文件，同时请求涌入。

将更改保存到 Web.config 文件时没有丢弃任何请求。

在加载新设置时，我确实观察到了 CPU 活动的短暂峰值，但实际上几乎看不到。

我能够通过使 Web.config 文件格式错误并保存它来证明设置正在加载。这立即导致请求开始失败。

令我惊讶的是process id 并没有随着 Web.config 的编辑而改变。我对 IIS 重叠回收的理解是让 IIS 启动一个新的 w3wp.exe 进程，然后关闭旧的进程。这将意味着不同的进程ID。所以我不认为重叠回收在这里发挥作用。

由于process id 是相同的，所以我认为它是一个完全独立的机制来加载/卸载AppDomain。 this document似乎支持这个，相关位转载如下：

配置更改导致应用程序域重新启动

Web.config 文件中配置设置的更改间接导致要重新启动的应用程序域。此行为是设计使然。你可以选择使用 configSource 属性来引用外部进行更改时不会导致重新启动的配置文件。有关详细信息，请参阅继承的常规属性中的 configSource 按部分元素。

TLDR

Overlapping Recycle 或残酷的停止/启动行为都不是由 Web.config 编辑引起的。 AppDomain 使用新设置重新加载，不会中断请求处理。

http://msdn.microsoft.com/en-us/library/ackhksh7.aspx

【讨论】：

干得好！我经常想知道这些差异，以及为什么与应用程序池回收相比，配置更改通常更快地“重新启动”。
是的，在 ASP.NET（不是 Core）中编辑 web.config 将保持相同的进程 ID。过程是一样的。它只是重新加载 AppDomain。但这发生在同一个过程中。然而，对于 ASP.NET CORE，情况有所不同。 w3wp 进程的新副本由AspNetCoreModule 启动

【解决方案2】：

编辑（或触摸）web.config 不会触发“良好的重叠回收”。如上所述，请求进程不会被“中断”，但新的传入请求必须等到新的工作进程完成初始化。所以根据初始化的时间，会有明显的中断。我注意到在 IIS7.5 中托管的 WCF 服务应用程序上，我实现了 IProcessHostPreloadClient 来执行一些耗时的预加载工作。另一方面，通过在 IIS 管理器中单击应用程序池的上下文菜单项来进行“回收”，将产生很好的重叠：只要新请求在 preload 方法上工作，旧的工作进程就会处理新的传入请求。

【讨论】：