IIS 6.0 has a web site running under an application pool with a default timeout time of 20 minutes.
Unless it is a high traffic site, the site will fall out of memory (memory is recycled) and need to be JIT’ted – for complex sites this time can lead to timeouts to the end user, even worse if a multitier application as the top tier calls the next and each has a JIT issue.
Unless you can change the application pool settings to suit yourself, (most servers expect you to share with other websites), then some keep-alive method is needed.
The website itself can be kept alive with a tool such as www.internetseer.com – at the same time providing a site uptime report but this is not useful to middle tier app servers for example – unless pinging a web page happens to call the middle tier code.
Therefore a keep alive service may need to be used for the app tier to keep it alive.
The issue is covered here:
|IIS 6.0 Application pool recycling – David Wang|
|The option exists because there are circumstances that make the option useful. Idle timeout allows reclaim of resources so that you can potentially run more code than you can simultaneously. In the case of dedicated servers, if you have provisioned the server hardware to be sufficient for your application, then idle timeout is clearly unnecessary and probably detrimental to performance/reliability. However, in the case of shared hosting, idle timeout allows you to pack thousands of users and their websites onto one box to maximize utilization of resources by ACTIVE applications. Since IIS6 is a generic and configurable server, it needs to have options to handle these and MORE diverse workloads. Obviously, not all options are optimal for all applications — if that was the case, one never needs to tune settings. Nor are the defaults guaranteed to be best for any given application.. In particular, the defaults are tuned towards ASP/COM applications, which completely contradict with hosting ASP.Net applications. Thus, you always have to understand and tune such settings depending on your circumstance. Basically, IIS assumes that for users that care about these settings, they will figure out what to customize and with what values. If the user does not care, then the defaults are by definition sufficient. It doesn’t matter if the defaults are not optimal if the user does not care about it either. Optimal behavior requires user interaction.
http://blogs.msdn.com/David.WangPosted at 10:35 AM by Dyball, Robert | Permalink | Email this Post | Comments (0)