最近我们想解决第一次请求时 IIS 加载缓慢的问题，经过研究，我发现 IIS7.5+ 有一个名为“应用程序初始化”的功能，这可能是我需要的。
但是在我尝试应用之前我必须了解该机制，这是我的理解：
使用默认 IIS 设置：
第 4、5 步使第一个请求反应不那么灵敏。
设置应用程序初始化：
现在第一个请求是响应的，因为它确实不是对服务器的第一个请求，有时是在“假”请求启动应用程序加载之前。
我想知道的是：
我的理解正确吗？
设置应用初始化的时候，worker进程还在被杀死，但是紧接着又创建了一个新的，是这样吗？
【问题讨论】：
这就是它的工作原理。正如您所提到的，如果没有应用程序初始化，一旦工作进程被杀死，它不会重新启动，直到向它发送请求。在第一次请求时，将启动一个新的工作进程 (W3WP.exe) 并开始加载应用程序。应用程序的这种冷启动通常会使第一个请求的响应速度降低。例如。如果是 ASP.NET 应用程序，第一个请求会触发临时 ASP.NET 文件的重新编译，这在中等规模的企业应用程序中可能需要几秒钟。
如果您查看应用程序初始化的设置，您会发现它有两个主要部分：
第 1 步告诉 IIS 在重新启动或 IISReset 时自动重新启动 IIS 工作进程。 （您可以在 TaskManager 中轻松看到这一点 - 只需执行第 1 步并执行 IISReset，您应该会看到现有的 W3WP.exe 进程被删除并创建了一个新进程）
第 2 步告诉 IIS 发出初始假/虚拟请求，该请求将完成您的 Web 应用程序的所有必需初始化。例如。对于 ASP.NET 应用程序，这基本上会触发所有 ASP.NET 文件的编译，因此下一个请求 - 对页面的实际第一个请求不会遇到与应用程序初始化相关的长时间延迟。
虽然保持使用脚本轮询应用程序以防止其空闲的传统方法确实可以完成这项工作，但 ApplicationInitalization 模块使这项工作变得更加容易。您甚至可以让 IIS 向自定义预热脚本发出虚拟请求，该脚本的作用远不止简单的页面加载 - 预加载多个网页的缓存，提前生成/执行任何可能需要更长时间的任务等。
官方文档在这里：
【讨论】：
根据我的经验，您的理解是正确的。早在 2014 年，我就在性能测试场景中首次遇到此功能。我将其 ping 部分自定义编码到监控作业中：O
"应用程序初始化模块基本上可以让你开启 在应用程序池和站点/IIS 应用程序上预加载，这 本质上，只要 应用程序池已启动。这意味着您的 ASP.NET 应用程序立即激活，Application_Start 被触发 确保您的应用始终保持正常运行。” - Rick Strahl
Official detailed docs 在 MSDN 站点上，据我所知，IIS 7.5 和 8.0 之间的配置方式没有太大变化。
【讨论】：