从共享驱动器托管的网站中服务器特定的 web.config
背景信息：文件复制很蹩脚
目前，我们有一个大规模、高流量的 ASP.NET Web 应用程序，在 8 个不同的 IIS 服务器之间进行负载平衡。 由于站点的性质，.aspx 文件和 .ascx 控件的微小更改全天频繁发生，经过测试并发布后，会通过 xcopy 部署定期复制到每个公共 Web 服务器。 10分钟。
当然，这是极其低效的，因为每台服务器都必须有整个站点的冗余副本，而且我们希望消除 10 分钟的发布延迟。
可能的改进：从共享存储托管
我们现在可以选择使用带有 iSCSI 接口的集中存储来集中托管整个站点，每个服务器都认为远程存储是本地驱动器。 发布将是即时的、全系统的。
注意：无法通过 UNC 共享托管驱动器，因为站点结构中有很多不同的目录，每个目录都需要用于 ASP.NET 的 FileSystemWatcher 来监视更改，因此很快就会达到 SMB 最大命令计数。 是的，我们知道 MaxCmds 和 MaxMpxCt 注册表设置。
问题：Web.config 更改会触发大规模重新编译
我们预见到的问题是，对文件系统结构的某些更改可能会导致几乎所有已编译的 .aspx 或 .ascx 必须重新编译，导致请求排队并感觉服务器已关闭。 大多数资源不会在系统范围内使用，因此在更改时重新编译它们几乎不会导致资源出现问题。 站点上所有页面使用的全局母版页可能会导致这种情况，但这可以通过代码轻松管理。
罪魁祸首是 web.config 文件。 对 web.config 文件的更改会导致整个 Web 应用程序回收并重新编译。 因此，我们目前不复制 web.config 更改。 任何 web.config 更改都需要将 Web 服务器从负载平衡器上移开，应用（并测试）更改，然后使用垃圾请求预热服务器，然后再将其放回负载平衡器上。
但是，如果 web.config 文件（与 Web 应用程序的目录结构的其余部分一样）位于集中存储上，则只有该文件的一份副本，并且无法再对各个服务器进行修补和预热。
问题
有没有办法让 ASP.NET Web 应用程序从名为 Web.config 的文件以外的源获取行进命令？
理想情况下，每台服务器都有一个文件，例如：
- default.aspx
- global.asax
- Web-ServerA.config
- Web-ServerB.config
- ...
- Web-ServerN.config
名称“web.config”在哪里定义？ 是否有可以针对每个服务器进行设置的注册表设置？ 是否可以在 machine.config 或全局 web.config 中创建一个条目来指定要使用的文件？
超出范围的事情
我很清楚，我并不是在问如何为调试、测试和实时使用不同的 AppSettings。 还有其他主题涵盖了这一点，并且我的所有 web.config 在大多数情况下都是相同的，唯一需要它们不同的时间是在执行更新时。
我们没有使用 web.config 来获取任何 appSettings 信息； 这是针对真正重要的内容，例如程序集引用、httpHandler 定义和其他无法数据库化的 system.web 设置。
更新
我尝试在注册表中搜索 Web.config，但除了指出我最近编辑过 web.config 文件的应用程序之外什么也没找到，而我显然经常这样做。 那里没有帮助。
Background Info: File Replication is Lame
Currently, we have a massive, high-traffic ASP.NET web application load-balanced across 8 different IIS servers. Due to the nature of the site, minor changes to .aspx files and .ascx controls happen frequently throughout the day, and after being tested and published to live, are replicated out to each of the public webservers through xcopy deployment on a scheduled basis every 10 minutes.
Of course this is incredibly inefficient, as each server must have a redundant copy of the entire site, and we would like to eliminate the 10-minute publishing lag.
Possible Improvement: Hosting from Shared Storage
We now have the option to use centralized storage with an iSCSI interface to host the entire site centrally, with each server believing that the remote storage is a local drive. Publishes would be instantaneous and system-wide.
Note: Hosting the drive off a UNC share is not possible, as there are so many different directories in the site structure, each requiring a FileSystemWatcher for ASP.NET to monitor for changes, that the SMB maximum command count is quickly reached. Yes, we know about the MaxCmds and MaxMpxCt registry settings.
The Problem: Web.config changes trigger massive recompiles
The problem we forsee is that certain changes to the file system structure can cause nearly every compiled .aspx or .ascx to have to recompile, causing queued requests and a perception that the server is down. Most resources are not used system-wide and so recompiling them on a change causes hardly a blip in resources. A global master page used by all pages on the site can cause this, but this can easily be managed by code.
The primary culprit is the web.config file. Changes to the web.config file cause the entire web application to recycle, and recompilations to occur. So, we currently don't replicate web.config changes. Any web.config changes requires bringing the web server off the load balancer, applying (and testing) the changes, and then warming the server up with junk requests before it is placed back on the load balancer.
However, if the web.config file, like the rest of the web application's directory structure, is located on centralized storage, there is only one copy of the file, and individual servers could not be patched and warmed up anymore.
The Question
Is there a way to get an ASP.NET web application to take its marching orders from a source other than a file named Web.config?
Ideally there would be one file per server, for example:
- default.aspx
- global.asax
- Web-ServerA.config
- Web-ServerB.config
- ...
- Web-ServerN.config
Where is the name "web.config" defined anyway? Is there a registry setting that could be set on a per-server basis? Is there an entry that could be made in the machine.config or the global web.config to specify what file to use?
Things Out Of Scope
Just so I am clear, I am not asking how to have different AppSettings for debug, test, and live. There are other topics that cover this, and all my web.configs will be identical most of the time, the only time I need them to be different is when an update is being performed.
We aren't using the web.config for any appSettings information; this is for the really important stuff, like assembly references, httpHandler definitions, and other system.web settings that can not be databased.
Update
I tried searching the registry for Web.config, and found nothing except for applications that noted that I had recently edited web.config files, which I apparently do a lot. No help there.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我的第一个问题是你在 web.config 和 web.config 中保留了什么？ 你能把它移到数据库吗？ 我们将每个配置设置保存在数据库的表中，并使用 machine.config 来存储数据库连接信息。
不确定这对您来说需要多少重写，但它会避免您的问题。
另一种选择是将配置项存放在外部文件中并从 web.config 引用它。 在 aspnet wp 被回收之前，对该文件的更改不会被重新读取，但允许您更改设置，然后通过 IISRESET 循环每个服务器。
My first question would be what are you keeping in the web.config & can you move it to a database? We keep every config setting in a table in our database and use the machine.config to store the db connection information.
Not sure how much of a rewrite that would be for you, but it would avoid your issue.
Another option would be to house your configuration items in an external file and reference it from the web.config. Changes to that file would not be re-read until the aspnet wp was recycled but would allow you to change setting and then cycle each server via an IISRESET.
只是好奇，你使用什么文件系统？ NTFS 不是共享存储文件系统。 换句话说，一次不能有多个节点写入文件系统。
我建议在 IIS 中的站点下建立虚拟目录。 这可能需要对代码布局进行一些重组，但不应太大。 因此，您将拥有站点的根主目录以及特定于该计算机的 web.config，然后将 vdir 映射到您设置的任何共享文件系统资源。
Just curious, what filesystem are you using? NTFS is not a shared storage file system. In other words you can't have more than one node writing to the filesystem at a time.
I would suggest virtual directories under the site in IIS. This will probably require a little bit of restructuring the layout of your code, but shouldn't be too major. So, you would have the root home dir of the site with the web.config that is specific to that machine and then a vdir mapped to whatever shared filesystem resource you setup.