编辑Web.config文件是否触发重叠的回收或应用程序池的开始+停止? [英] Does editing a Web.config file trigger an overlapping recycle or a start+stop of the application pool?

查看:206
本文介绍了编辑Web.config文件是否触发重叠的回收或应用程序池的开始+停止?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有重叠回收为我的ASP.NET MVC网站配置.

I have Overlapping Recycling configured for my ASP.NET MVC site.

据我了解(来自这个问题),如果我回收应用程序池,这将启动一个新的w3wp.exe进程来承担被回收的进程的负载,并且只有在新进程初始化并承担了负载之后,旧进程才会关闭.而且,如果我停止/启动应用程序池,它会立即终止,而不会让进程正常退出或让替换进程先启动.

As I understand it (from this SO question), if I Recycle the Application Pool, this will spin up a new w3wp.exe process to take up the load of the one being recycled, and only when the new process is initialised and taking the load, will the old process be shut down. And if I stop/start the Application Pool, it does an immediate kill without letting the process quit gracefully or letting a replacement process spin up first.

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

我正在尝试确定是否需要从负载平衡的服务器场中取出一台服务器,并对服务器流量进行排他性操作以编辑配置设置.

I'm trying to decide if I need to take a server out of a load-balanced farm and do a drain-stop on the server traffic in order to edit configuration settings.

推荐答案

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

I decided to use science. I ran an experiment with my server under a load-testing tool, where I repeatedly edited and saved my Web.config file while requests were poured in.

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

No requests were dropped when changes were saved to the Web.config file.

在加载新设置的过程中,我确实观察到CPU活动出现了短暂的高峰,但实际上几乎没有引起注意.

I did observe a short spike in CPU activity while the new settings were loaded, but really barely noticeable at all.

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

I was able to prove that the settings were getting loaded by making the Web.config file badly formatted and saving it. This immediately caused requests to start failing.

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

What surprised me is that the process id did not change with a Web.config edit. My understanding of the IIS Overlapping Recycle was for IIS to start a new w3wp.exe process, and then wind down the old one. Which would have meant a different process id. So I don't think Overlapping Recycle is kicking in here.

由于process id相同,所以我认为它是一个完全独立的机制,用于加载/卸载AppDomain. 本文档似乎支持此方法,相关内容如下:

Since the process id is the same, then I reason that its a totally separate mechanism which loads/unloads the AppDomain. This seems to be supported by this document, the relevant bit is reproduced below:

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

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

Changes to configuration settings in Web.config files indirectly cause the application domain to restart. This behavior occurs by design. You can optionally use the configSource attribute to reference external configuration files that do not cause a restart when a change is made. For more information, see configSource in General Attributes Inherited by Section Elements.

TLDR

重叠回收或残酷的停止/启动行为均不是由Web.config编辑引起的.重新加载了AppDomain的新设置,而不会中断请求处理.

Neither Overlapping Recycle, or the brutal stop/start behaviour are caused by a Web.config edit. The AppDomain is re-loaded with the new settings without interruption to request processing.

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

这篇关于编辑Web.config文件是否触发重叠的回收或应用程序池的开始+停止?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆