克服 *secondary* 初始 ASP.Net 应用程序启动时的编译（？）暂停？答案

【问题标题】：Overcome compilation(?) pause on *secondary* initial ASP.Net application startup?克服 *secondary* 初始 ASP.Net 应用程序启动时的编译（？）暂停？
【发布时间】：2009-08-04 20:02:20
【问题描述】：

在将 ASP.Net 应用程序部署到新服务器后，第一个点击该应用程序的用户会暂停很长时间，这可能是因为该应用程序正在执行其初始编译。但是，这种暂停似乎也发生在应用程序超时并从内存中卸载自身之后。

第一次编译是可以容忍的，因为它只发生一次，但在我看来，第二次编译应该是不必要的......是否有解决这个问题的解决方法？能够延长应用程序超时会很好，但我只看到了一种延长会话超时的方法，我不想这样做，因为这会使所有用户会话在内存中保留很长一段时间。

【问题讨论】：

我并不肯定，但您可以对 IIS 6 和 IIS 7 中的应用程序池进行一些调整，这会有所帮助。

标签： asp.net iis application-pool

【解决方案1】：

这是 IIS 关闭工作进程 - 默认是 20 分钟的空闲时间。在 IIS6 中，您可以配置 app pool and turn off the Idle timeout（在性能选项卡上）。在 IIS7 中，it's in the Advanced Settings。

【讨论】：

【解决方案2】：

使工作进程保持活动状态的一种常见方法（尽管在我看来有点骇人听闻）是让某些程序定期向应用程序中的某个 URL 发出 Web 请求。

您可以通过使用aspnet_compiler.exe 预编译 ASP.NET 应用程序来缩短初始启动时间。这不会将初始请求时间减少到零（它仍然需要创建工作进程并进行其他内务处理。）但它会显着减少它。

【讨论】：

【解决方案3】：

我确实为 IIS 中的应用程序池找到了一些推荐设置。这些设置的预期结果是减少应用程序需要经历启动周期的次数。这些设置应适用于 IIS 6 和 IIS 7：

回收工作进程：禁用。仅当您有多个网站并尝试隔离进程时才使用此选项。
在空闲（以分钟为单位的时间）后关闭工作进程：禁用，除非您正在共享服务器上的资源。禁用此设置后，您的网站不应卸载，以确保您的网站的启动时间尽可能短。

【讨论】：

我反对禁用工作进程回收的建议。一个健康的应用程序不应该注意到由于重叠回收而造成的差异，一个行为不端的应用程序将大大受益。老实说，我认为启用它的缺点很小。