循环 IIS 应用程序池导致首次用户体验缓慢
当我通过 IIS MMC 回收 Web 应用程序的应用程序池时，第一个在 Web 应用程序中请求页面的用户将体验到站点响应非常慢。 在最初的请求之后，之后的每个页面都很好。 用户还可以注销网站，稍后再回来，速度很快。 我关心的是网站的第一次初始加载。 如果我要编写一个脚本在凌晨 3 点重新启动应用程序池，我还能做什么
a.) 模拟访问该网站的用户并实现初始缓慢加载，从而使应用程序“准备就绪”为早上的用户。
或
b.) 告诉应用程序池缓冲内存等，而无需用户启动此过程。
When i recycle the application pool for my web app via IIS MMC, the first user to request a page within the webapp will experience a really slow response from the site. After that initial request, every page there after is fine. The user could also log off the site, come back later and the speeds are quick. My concern is with the first, initial load of the site. If i were to write a script to restart the application pool at 3am in the morning, what else can i do to either
a.) impersonate a user visiting the site and getting that initial slow load to happen, thus making the app "ready" for the users in the morning.
or
b.) tell the app pool to spool up the memory and such without a user having to initiate this process.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
首先，您不需要脚本来在凌晨 3 点回收应用程序。 应用程序池有回收时可供选择的设置。 默认情况下，我认为它们每 29 小时回收一次，这是一个奇怪的设置，我建议更改它。 否则，您会在一天中的任意时间接到声称丢失会话的电话。
我必须假设您在相关的应用程序池中有一个 ASP.NET 应用程序。 在第一次请求时，延迟主要是由于 ASP.NET 工作进程需要编译网站和/或加载运行时所需的 DLL。 为了解决此问题，大多数使用保持活动任务，该任务可以定期向站点发出请求以确保其完全加载。 马特的建议也是一个很好的建议，但只有当您自己回收应用程序池时才能解决问题。 应用程序池可以出于多种其他原因自行回收，并且保持活动状态将能够在大多数时间保持加载。
First, you don't need a script to recycle the app at 3 AM. The app pools have settings to choose when they recycle. By default, I think they recycle every 29 hours, which is an odd setting and I recommend changing it. Otherwise, you'll get calls claiming lost sessions at random times of the day.
I must assume you have an ASP.NET application in the app pool in question. Upon first request, the delay is mostly due to the ASP.NET worker process needing to compile a Web site and/or load DLLs required at runtime. To solve this issue, most use a keep-alive task which can make regular requests to the site to ensure that it is fully loaded. Matt's suggestion is also a good one, but will only solve the issue when you are recycling the app pool yourself. App pools can recycle on their own for any number of other reasons and the keep-alive will be able to keep things loaded most of the time.
一切都发生在网站的第一次加载时。 你唯一能做的就是在回收后模拟对网站的请求。 这可以通过一个简单的应用程序来完成。 在 .NET 中执行此操作的最简单方法是使用 HttpWebRequest 类。
Everything happens on the first load of the site. The only thing you could do is simulate a request to the website after recycling. This can be done with a simple application. The easiest way to do this in .NET would be to use the HttpWebRequest class.
我遇到了类似的问题。 首次加载时，JIT 编译器需要将 MSIL 转换为机器代码。 通常，如果这不是第一次使用该应用程序，则此操作可以很快完成，并且可以从“临时 ASP.NET 文件”文件夹卷影副本中完成。 您的应用程序程序集会在首次加载应用程序时复制到此处，以便应用程序 dll 可以在实际位置进行热交换，而不会出现“使用中”类型错误。
我离题了，JIT 编译器会根据需要编译程序集，这通常非常快。 当您使用签名的程序集并且执行 JIT 编译的用户（即应用程序池用户）没有 Internet 访问权限时，这种情况会发生变化。 在这种情况下，它只会停留在那里大约 10-20 秒，同时尝试验证它无法到达的互联网上的签名。
当我们遇到这个问题时，我们使用的是企业库程序集，因此在应用程序池回收后，JIT 编译时间不是花费几秒钟，而是在某些情况下花费了一分钟多的时间，因为它等待签名验证互联网请求超时。
因此，要么在 JIT（配置设置）期间关闭程序集上的签名验证，要么为应用程序池用户提供 Internet 访问权限。
I was experiencing a similar issue. On first load the JIT compiler needs to convert the MSIL into machine code. Usually this is done very quickly and is done from the "Temporary ASP.NET Files" folder shadow copy if this is not the first time the application has been used. Your application assemblies get copied here on the first load of the application so the applications dll's can be hot swapped in the actual location without getting the "in use" type errors.
I digress, the JIT compiler compiles up the assemblies as they're needed which is usually pretty quick. This changes when you use signed assemblies and the user doing the JIT compilation (ie the App pool user) doesn't have internet access. In that case it will just sit there for about 10-20 seconds while it tries to verify the signature on the internet which it can't reach.
When we had this problem we were using Enterprise Library assemblies so instead of the JIT compile time taking a few seconds after app pool recycle it was taking over a minute in some cases as it waited to timeout on the signature verification internet requests.
So either turn off signature verification on your assemblies during JIT (a config setting) or give the app pool user internet access.
这是一个老问题，但我最近有一些这方面的经验，并认为我应该发布它。 根据您的具体情况，您可以执行多种操作。
它缓慢的原因是 IIS 工作进程在一段时间后进入睡眠状态。 此设置称为空闲超时，如果您想禁用该功能，可以将其设置为 0。 但是，在做出这样的改变之前我会研究一下。
此外，当 IIS 启动时，它会在您的 bin 中注册 DLL。 如果您的站点很小，则可能没有太多 DLL（标准 .NET DLL 除外）。 如果您有许多（也许是一些未使用的）DLL，它们仍然需要处理。 如果您删除旧的 DLL/代码，IIS 将不再浪费时间处理它们，并且会更快地重新启动。
我们有一个 DotNetNuke 站点，其中包含大约 35 个不再使用的“旧版”模块，但仍位于 /bin 文件夹中。 我们删除了 /bin 中的模块和 DLL，网站回收时间减少了一半。
还有一件事。 您可以配置一个定期加载的保持活动页面，这样网站就不会关闭。 我知道我们的托管提供商提供此服务。 我们的网站上有一个简单的 ASPX 页面，他们每 30 分钟访问一次，以确保网站在内存中保持加载状态。
This is an old question, but I've had some recent experience with this and thought I'd post it. There are several things you can do, depending on your situation.
The reason it slow is the IIS worker process go to sleep after a certain time period. The setting for this is called Idle Timeout and can be set to 0 if you want to disable that feature. But, I would research this before making a change like that.
Also, when IIS starts up, it registers the DLLs in your bin. If you have a small site, there probably aren't too many DLLs (other than the standard .NET DLLs). If you have many (maybe some unused) DLLs, they still need to be processed. If you remove the old DLLs/Code, IIS will no longer waste time processing them and will restart faster.
We have a DotNetNuke site that had about 35 'legacy' modules that were no longer in use, but were still in the /bin folder. We removed the modules and DLLs in the /bin and the website recycle time was cut in half.
One more thing. You could configure a Keep Alive page that gets loaded periodically so the site doesn't shut down. I know our hosting provider offers this service. We have an simple ASPX page on the site that they hit every 30 minutes to make sure the site stays loaded in memory.