cycling IIS app pool cause slow first user experience

Question

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.

Answer 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.

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.

Answer 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.

Answer 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.

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.

Answer 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.

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.