IIS7.5 +：它是描述应用程序初始化功能的正确方法吗？

Question

最近我们想要满足第一次请求的IIS缓慢加载问题，在我做了一些研究之后，我发现IIS7.5 +有一个名为“Application Initialization”的功能，这可能是我需要的。

不过，我已经明白了机制之前，我尝试应用它，这是我的理解：

用默认的IIS设置：

1. 应用程序池空闲20分钟后
2. 相应的工作进程被终止
3. 第一次请求进入
4. IIS开始创建一个新的工作进程
5. IIS开始加载应用
6. 应用程序被加载

和步骤4之后，客户机可以看到的，5使第一请求不那么敏感。

随着应用程序初始化设置：

1. 20分钟
2. 相应的工作进程被杀死
3. IIS开始创建一个新的工作进程
4. IIS后的应用程序池空闲通过“假”请求开始加载应用程序
5. 第一次请求牛逼进来
6. 客户端可以看到应用程序加载

后现在的第一个请求响应因为实际上它不是服务器的第一个请求，有时之前有一个“假”的请求，这踢装载的应用程序。

---

我想知道的是：

是我的理解是否正确？

当设置了应用程序初始化时，工作进程仍然被终止，但是在它之后创建了一个新进程，情况如何？

Answer 1

这几乎是如何工作的如果没有应用程序初始化，正如你所提到的那样，一旦工作进程被终止，它就不会重新启动，直到发送请求为止。 ，一个新的工作进程（W3WP.exe）被启动并开始加载应用程序，而这个应用程序的冷启动通常会使fir st请求不太敏感。例如。如果它是一个ASP.NET应用程序，则第一个请求会触发重新编译临时ASP.NET文件，而这在中等规模的企业应用程序中可能需要几秒钟的时间。

如果你看一下应用程序初始化的设置，你会看到有两个主要部分是：

1. 您需要设置与网站相关联的应用程序池的STARTMODE AlwaysRunning
2. 您需要设置在ApplicationPool

preloadEnabled考虑到部分道路（路径网站）

步骤1告诉IIS自动重新启动IIS辅助进程，只要有重新启动或IISReset。 （你可以很容易地看到这在TaskManager中的行动 - 只做第1步，做一个IISReset，你应该看到现有的W3WP.exe进程被删除，并且一个新的被创建）

步骤2告诉IIS做出最初的虚假/虚拟请求，以完成您的Web应用程序所需的所有初始化。例如。对于一个ASP.NET应用程序来说，这基本上会触发所有ASP.NET文件的编译，以便下一个请求 - 对页面的实际首次请求不会遇到与应用程序初始化相关的长时间延迟。

虽然传统方法保持使用脚本来轮询应用程序以防止它闲置可以完成这项工作，但ApplicationInitalization模块使得工作更容易。您甚至可以让IIS向虚拟请求发出一个自定义热身脚本，它不仅仅是简单的页面加载 - 预加载多个网页缓存，提前生成/执行任何可能需要更长时间的任务。

官方单证这里：

IIS 7.5

IIS 8.0

Answer 2

根据我的经验，您的理解是正确的。我第一次遇到了这个能力，在性能测试场景的方式回到2014年，我的自定义编码到这个监视作业的平部分：o

“的应用程序初始化模块基本上可以让你打开 预压应用程序池和站点/ IIS应用程序，其中 实质上在启动 应用程序池时通过IIS管道发出请求。这意味着您的 ASP实际上是有效的。NET应用变得活跃，立即的Application_Start被激发 确保您的应用程序保持正常运行在任何时候“ - Rick Strahl

Official detailed docs都在MSDN网站，从我所看到的没有太大的IIS 7.5之间变化配置方式为：