follow url If you’re running a Windows .NET web app, like DotNetNuke, it must be compiled by IIS before serving it up. When a page request comes in, IIS checks to see if the compiled bytecode is loaded in the iis application pool. If so, it uses it and if not, it loads all files and compiles them, puts them into the iis application pool, then serves the page.
http://mikeoverton.com/they-moved-the-shower-head/ We refer to this “wait while I compile the site before serving up the page” page load as the “cold start” page load. This can add 1-10 seconds of page response time, depending on how complex the .NET app is, the amount of disk i/o required, and how busy the web server is (i.e. available CPU) at the time of compile.
This article is meant to provide a tip to website performance enthusiasts for keeping their sites warm and reducing the likelihood of site visitors waiting for the “cold start” page load.
If you use shared Web Hosting, however, you adopt the settings of your web hosting provider. In a shared environment, it’s common to see settings of 20 minutes idle timeout, but the settings can vary from provider to provider. Shared hosting providers must do this, because there isn’t enough memory to hold everyone’s app in the iis application pool at the same time.
What can you do about it?
If a “cold start” once in awhile on your site isn’t a concern for you, then no action is required.
If on the other hand, you want to reduce the chance of your site visitors getting a “cold start” load page, and you’re the admin of your server, and you’re running one or just a few applications, try changing the iis application pool timeout to zero, or make it a much bigger value.
If you’re on a shared web hosting plan, your site must get enough traffic to prevent your app from getting timed out of the iis application pool. There are a few ways to do this. The first (and best) way is, of course, to get enough natural traffic to keep your site warm. If you’re just starting out, however, it may take a while to build your traffic to this level.
Another option is to point a website monitoring tool such as Pingdom at your site. Pingdom will fetch your site once a minute to monitor uptime and response time. And as a bonus, it’ll keep your site in the application pool. (Do note that if everybody did this, it could become a problem for the shared hosting provider, due to the memory resources required to hold all apps in the iis application pool at the same time. So be kind, and use sparingly. With great power comes great responsibility.)