当我通过 IIS MMC 为我的 Web 应用程序回收应用程序池时，第一个在 Web 应用程序中请求页面的用户将体验到来自站点的非常慢的响应。在该初始请求之后，之后的每一页都很好。用户也可以注销网站，稍后再回来，速度很快。我关心的是网站的第一个初始加载。如果我要编写一个脚本在凌晨 3 点重新启动应用程序池，我还能做什么
a.) 模拟访问该站点的用户并让最初的缓慢加载发生，从而使应用程序在早上为用户“准备好”。
或者
b.) 告诉应用程序池缓冲内存等，而无需用户启动此过程。
问问题
5898 次
4 回答
1
首先，您不需要脚本即可在凌晨 3 点回收应用程序。应用程序池在回收时具有可供选择的设置。默认情况下，我认为它们每 29 小时回收一次，这是一个奇怪的设置，我建议更改它。否则，您将在一天中的随机时间接到声称丢失会话的电话。
我必须假设您在有问题的应用程序池中有一个 ASP.NET 应用程序。在第一次请求时，延迟主要是由于 ASP.NET 工作进程需要编译网站和/或加载运行时所需的 DLL。为了解决这个问题，大多数人使用保持活动状态的任务，它可以定期向站点发出请求以确保它完全加载。Matt 的建议也是一个不错的建议，但只有在您自己回收应用程序池时才能解决问题。应用程序池可以出于任何其他原因自行回收，并且保持活动将能够在大部分时间保持加载。
于 2010-04-19T16:42:53.290 回答
0
我遇到了类似的问题。首次加载时，JIT 编译器需要将 MSIL 转换为机器代码。通常这会很快完成，如果这不是第一次使用应用程序，则可以从“Temporary ASP.NET Files”文件夹卷影副本中完成。您的应用程序程序集在第一次加载应用程序时被复制到此处，因此应用程序 dll 可以在实际位置进行热交换，而不会出现“使用中”类型错误。
我离题了，JIT 编译器根据需要编译程序集，这通常很快。当您使用签名程序集并且执行 JIT 编译的用户（即应用程序池用户）没有 Internet 访问权限时，这种情况会发生变化。在这种情况下，它只会在那里停留大约 10-20 秒，同时它会尝试验证它无法访问的 Internet 上的签名。
当我们遇到这个问题时，我们使用的是企业库程序集，因此在应用程序池回收后需要几秒钟的 JIT 编译时间，在某些情况下它会花费一分钟以上，因为它等待签名验证 Internet 请求超时。
因此，要么在 JIT（配置设置）期间关闭程序集的签名验证，要么让应用程序池用户访问 Internet。
于 2013-02-25T23:54:04.023 回答
0
一切都发生在网站的第一次加载。您唯一能做的就是在回收后模拟对网站的请求。这可以通过一个简单的应用程序来完成。在 .NET 中执行此操作的最简单方法是使用HttpWebRequest类。
于 2009-07-16T15:33:56.360 回答
0
这是一个老问题，但我最近对此有一些经验，并认为我会发布它。根据您的情况，您可以做几件事。
它缓慢的原因是 IIS 工作进程在一段时间后进入睡眠状态。对此的设置称为空闲超时，如果您想禁用该功能，可以将其设置为 0。但是，在做出这样的改变之前，我会先研究一下。
此外，当 IIS 启动时，它会在您的 bin 中注册 DLL。如果您有一个小型站点，则可能没有太多 DLL（标准 .NET DLL 除外）。如果您有很多（可能是一些未使用的）DLL，它们仍然需要处理。如果您删除旧的 DLL/代码，IIS 将不再浪费时间处理它们，并且会更快地重新启动。
我们有一个 DotNetNuke 站点，其中包含大约 35 个不再使用的“旧”模块，但仍在 /bin 文件夹中。我们删除了 /bin 中的模块和 DLL，网站回收时间减少了一半。
还有一件事。您可以配置一个定期加载的Keep Alive页面，这样网站就不会关闭。我知道我们的托管服务提供商提供这项服务。我们在网站上有一个简单的 ASPX 页面，他们每 30 分钟点击一次，以确保网站保持加载在内存中。
于 2015-04-23T01:49:44.397 回答