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
当我通过IIS MMC回收我的Web应用程序的应用程序池时,第一个在webapp中请求页面的用户将会遇到来自该站点的非常慢的响应。在初始请求之后,之后的每个页面都很好。用户也可以注销网站,稍后再回来,速度很快。我担心的是网站的第一次初始加载。如果我要在凌晨3点写一个脚本来重启应用程序池,那我还能做些什么
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.
a。)冒充访问该网站的用户并使该初始缓慢加载发生,从而使该应用程序在早上为用户“准备好”。
or
b.) tell the app pool to spool up the memory and such without a user having to initiate this process.
b。)告诉应用程序池清空内存,而无需用户启动此过程。
4 个解决方案
#1
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.
首先,您不需要脚本在凌晨3点回收应用程序。应用程序池具有可在回收时选择的设置。默认情况下,我认为他们每29小时回收一次,这是一个奇怪的设置,我建议更改它。否则,您将在当天的随机时间接到要求丢失会话的电话。
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.
我必须假设您在相关的应用程序池中有一个ASP.NET应用程序。在第一次请求时,延迟主要是由于ASP.NET工作进程需要编译Web站点和/或加载运行时所需的DLL。为解决此问题,大多数人使用keep-alive任务,该任务可以定期向站点发出请求以确保它已满载。马特的建议也很好,但只会在你自己回收应用池时解决问题。应用程序池可以出于任何其他原因自行回收,并且keep-alive将能够在大多数时间保持加载。
#2
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.
一切都发生在网站的第一次加载。您唯一能做的就是在回收后模拟对网站的请求。这可以通过简单的应用程序完成。在.NET中执行此操作的最简单方法是使用HttpWebRequest类。
#3
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.
我遇到了类似的问题。首次加载时,JIT编译器需要将MSIL转换为机器代码。通常这可以非常快速地完成,并且可以从“Temporary ASP.NET Files”文件夹卷影副本完成,如果这不是第一次使用该应用程序。在应用程序的第一次加载时,应用程序集将被复制到此处,以便应用程序dll可以在实际位置进行热交换而不会出现“使用中”类型错误。
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.
我离题了,JIT编译器会根据需要编译程序集,这通常非常快。当您使用签名程序集并且执行JIT编译的用户(即App池用户)没有Internet访问权限时,这会发生更改。在这种情况下,当它试图验证互联网上无法到达的签名时,它只会坐在那里大约10-20秒。
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.
当我们遇到这个问题时,我们使用的是企业库程序集,因此在应用程序池回收后花费几秒钟而不是JIT编译时间,在某些情况下,由于等待签名验证互联网请求超时,因此花费了一分钟。
So either turn off signature verification on your assemblies during JIT (a config setting) or give the app pool user internet access.
因此,要么在JIT(配置设置)期间关闭程序集上的签名验证,要么为应用程序池用户提供Internet访问权限。
#4
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.
它缓慢的原因是IIS工作进程在一段时间后进入休眠状态。此设置称为空闲超时,如果要禁用该功能,则可以设置为0。但是,我会在做出这样的改变之前对此进行研究。
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.
此外,当IIS启动时,它会在您的bin中注册DLL。如果你有一个小网站,可能没有太多的DLL(除了标准的.NET DLL)。如果你有许多(可能是一些未使用的)DLL,它们仍然需要处理。如果删除旧的DLL /代码,IIS将不再浪费时间处理它们并将更快地重新启动。
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.
我们有一个DotNetNuke站点,它有大约35个'遗留'模块,不再使用,但仍在/ bin文件夹中。我们删除了/ bin中的模块和DLL,网站的回收时间减少了一半。
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.
还有一件事。您可以配置定期加载的Keep Alive页面,以便站点不会关闭。我知道我们的托管服务商提供此服务。我们在网站上有一个简单的ASPX页面,它们每30分钟就会点击一次,以确保网站在内存中保持加载状态。
#1
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.
首先,您不需要脚本在凌晨3点回收应用程序。应用程序池具有可在回收时选择的设置。默认情况下,我认为他们每29小时回收一次,这是一个奇怪的设置,我建议更改它。否则,您将在当天的随机时间接到要求丢失会话的电话。
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.
我必须假设您在相关的应用程序池中有一个ASP.NET应用程序。在第一次请求时,延迟主要是由于ASP.NET工作进程需要编译Web站点和/或加载运行时所需的DLL。为解决此问题,大多数人使用keep-alive任务,该任务可以定期向站点发出请求以确保它已满载。马特的建议也很好,但只会在你自己回收应用池时解决问题。应用程序池可以出于任何其他原因自行回收,并且keep-alive将能够在大多数时间保持加载。
#2
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.
一切都发生在网站的第一次加载。您唯一能做的就是在回收后模拟对网站的请求。这可以通过简单的应用程序完成。在.NET中执行此操作的最简单方法是使用HttpWebRequest类。
#3
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.
我遇到了类似的问题。首次加载时,JIT编译器需要将MSIL转换为机器代码。通常这可以非常快速地完成,并且可以从“Temporary ASP.NET Files”文件夹卷影副本完成,如果这不是第一次使用该应用程序。在应用程序的第一次加载时,应用程序集将被复制到此处,以便应用程序dll可以在实际位置进行热交换而不会出现“使用中”类型错误。
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.
我离题了,JIT编译器会根据需要编译程序集,这通常非常快。当您使用签名程序集并且执行JIT编译的用户(即App池用户)没有Internet访问权限时,这会发生更改。在这种情况下,当它试图验证互联网上无法到达的签名时,它只会坐在那里大约10-20秒。
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.
当我们遇到这个问题时,我们使用的是企业库程序集,因此在应用程序池回收后花费几秒钟而不是JIT编译时间,在某些情况下,由于等待签名验证互联网请求超时,因此花费了一分钟。
So either turn off signature verification on your assemblies during JIT (a config setting) or give the app pool user internet access.
因此,要么在JIT(配置设置)期间关闭程序集上的签名验证,要么为应用程序池用户提供Internet访问权限。
#4
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.
它缓慢的原因是IIS工作进程在一段时间后进入休眠状态。此设置称为空闲超时,如果要禁用该功能,则可以设置为0。但是,我会在做出这样的改变之前对此进行研究。
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.
此外,当IIS启动时,它会在您的bin中注册DLL。如果你有一个小网站,可能没有太多的DLL(除了标准的.NET DLL)。如果你有许多(可能是一些未使用的)DLL,它们仍然需要处理。如果删除旧的DLL /代码,IIS将不再浪费时间处理它们并将更快地重新启动。
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.
我们有一个DotNetNuke站点,它有大约35个'遗留'模块,不再使用,但仍在/ bin文件夹中。我们删除了/ bin中的模块和DLL,网站的回收时间减少了一半。
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.
还有一件事。您可以配置定期加载的Keep Alive页面,以便站点不会关闭。我知道我们的托管服务商提供此服务。我们在网站上有一个简单的ASPX页面,它们每30分钟就会点击一次,以确保网站在内存中保持加载状态。