修改web.config后Azure VM上的Umbraco网站崩溃，求最优修改方案

首先得搞清楚为啥改完web.config网站会崩30分钟：修改web.config会直接触发IIS应用池强制回收，而Umbraco 7.1启动时要完成一系列初始化操作——编译所有视图、重建缓存池、建立数据库连接、加载文档类型和模板等等。Azure VM生产环境如果资源吃紧，或者初始化逻辑没优化，这个启动过程会慢到离谱，导致网站一直处于不可用状态，直到完全启动完成。

下面是我整理的具体优化建议，按优先级排序：

1. 绝对不要直接在生产环境改web.config！先在 staging 环境验证 #

先找个和生产环境配置完全一致的预发布环境，把你的修改先测一遍：一是确认配置本身没写错（比如连接字符串格式错、节点漏写），二是观察启动时间，提前预判会不会出问题。毕竟生产环境崩半小时可不是小事儿。

2. 启用IIS应用程序初始化，让应用自动预热 #

这是解决启动延迟最有效的办法之一——让应用池回收后自动启动应用，而不是等第一个用户请求来触发。具体配置：
在web.config的<system.webServer>节点里加这段代码：

<applicationInitialization doAppInitAfterRestart="true">
  <add initializationPage="/" hostName="你的生产域名" />
</applicationInitialization>

同时去IIS应用池设置里，把启动模式改成AlwaysRunning，空闲超时设成0（或者几小时），避免应用池因为空闲自动回收。

3. 把频繁修改的配置拆到外部文件 #

web.config本身一修改就触发回收，但如果把经常变的配置（比如appSettings、连接字符串）移到外部文件，修改外部文件就不会触发回收了。举两个例子：

• 拆分appSettings：
  在web.config里写：

  <appSettings configSource="AppSettings.config" />
  

  然后新建AppSettings.config文件，把原来的appSettings键值对放进去，以后改这个文件就行。
• 拆分连接字符串：
  同理，web.config里写：

  <connectionStrings configSource="ConnectionStrings.config" />
  

  连接字符串都放到外部文件里修改。

4. 优化Umbraco的启动速度 #

Umbraco 7.1本身启动不算快，能优化的地方不少：

• 关掉调试模式：确保web.config里<compilation debug="false" />，调试模式下视图编译速度会慢很多。
• 预编译视图：用Umbraco的视图预编译工具，把所有.cshtml视图编译成DLL，启动时就不用动态编译了。
• 清理冗余组件：检查下有没有装了不用的Umbraco包，或者自定义代码里有没有多余的初始化逻辑，删掉它们减轻启动负载。
• 优化数据库：给数据库加好索引，定期清理umbracoLog这类日志表，减少启动时数据库操作的耗时。

5. 选低峰时段修改web.config（如果必须改的话） #

要是你非得修改web.config本身（比如改一些核心配置节点），一定要挑网站流量最低的时候，比如凌晨。提前跟团队打个招呼，必要时也可以通知用户，把影响降到最小。

6. 监控启动过程，定位瓶颈 #

用Azure Monitor或者IIS日志盯着应用启动的耗时，看看是数据库连接慢，还是视图编译拖后腿，针对性地优化。比如如果是数据库慢，就去优化查询或者升级数据库资源；如果是视图编译慢，就赶紧预编译。

内容的提问来源于stack exchange，提问作者Manju