views:

1789

answers:

3

Scenario: I've an n-Tier enterprise ASP.NET application deployed using Web Deployment Projects. All tiers produce independent assemblies that is consumed by the ASP.NET application.

Problem: When I run the app. for the first time after deployment it takes lot of time to load dependent assemblies in memory. But once loaded its lighting fast app. In case if there are no users accessing the app, IIS unloads the assemblies from the memory and when a user tried to access the app on a later instance it goes on loading all the assemblies once again taking the same amount of time to load as it takes to do so for the first time.

I'm looking for a solution that enables me to keep my assemblies loaded into memory persistently overriding the volatile nature of assemblies towards memory residency.

Or any other solution that lets my users happily use the app resolving the mentioned problem.

+9  A: 

In IIS 6, go to the Application Pools section, and right-click > Properties on the pool which hosts the ASP.NET application in question. Go to the Performance tab and uncheck "Shutdown worker processes after being idle for:"

In IIS 7, go to the Connections pane and find Application Pools, and select Advanced Settings for the pool which hosts your application. Find the "Idle Timeout" property and set it to "0" (this disables it).

The default is 20 minutes of inactivity. By unchecking the box, once your AppDomain is loaded by the worker process, it will never die (unless you kill the process or something of course). By default, IIS will recycle the process when it reaches some limit, such as a memory cap, but it will also start a new one and "phase over" all incoming requests until the old one is unused, so as to minimize disruption.

I've also written a small c# class which will keep your ASP.NET application alive under normal circumstances. Since it runs within the application, obviously it can't stop IIS or anything else from explicitly killing the process, but it will keep the application "hot", e.g. the app will never go idle long enough for IIS to decide to shut it off.

If you do not have direct control over your IIS configuration (shared host, for example) your best bet is to have a small application running on a separate system - say, an always-on workstation - which hits your site every x minutes to keep the application pool from timing out. Nothing fancy - a simple WebRequest and a while() loop in a console application will do.

Rex M
I have a shared server. I do not have access to IIS configuration in that detail. Any way we can do this by code or configuration at application level ?
this. __curious_geek
@s_ruchit the control of the application pool and worker processes is at the IIS scope, so no. The most common solution in your situation is to have an application living on some other computer (say, an always-on workstation) which hits a page on your site every ~10-15 minutes. A service I have not personally used which claims to do that for you can be found at http://www.keepaliveforever.com/
Rex M
@Rex M: That was fabulous. I never thougt out of the box. It could be so simple! Thanks a ton. In fact we could write our own http client to keep the app alive always.
this. __curious_geek
I tried' uncheck "Shutdown worker processes after being idle for: '--> this has no effect, after a plenty of time the first request of my application is slow again !
Kottan
A: 

Blockquote a simple WebRequest and a while() loop in a console application will do.

I've tried the WebRequest solution and I keep getting a 500 internal error. If I use my browser on the same URL, however, this is not the case; the page just takes a long time to load.

webster
stackoverflow is about asking questions. If you have a question, you can ask a question (button top-right on every page), but don't use the Answer-feature for asking additional questions, use it for answers only.
Abel
A: 

I wrote a little C# console application that keeps my 4 sites alive every 10 mins via windows task scheduler. Life is once again good. We do not run the app from 2-5am just so the serves can do any cleanups of memory, if it even matters. for our sites there is rarely anyone on at those hours anyway.

Namoguy