Can I keep my application "ready for action" by using the global.asax?

[John Kotuby]

Hi all,

As I understand it, when an ASP.NET application ceases to be "live" in
server memory due to inactivity, that even if it is pre-compiled, upon the
first call to a page it does a final compile of a number of pages to machine
code.

In some cases this causes an unacceptable lag in performance for the first
user to the site, say early in the morning after there has been no activity.

I have heard that there are ways to cause a script to call a page when the
application closes, in order to keep that page and others in the same
folder/directory in machine code and responsive.

Can I initiate this action from the global.asax in the Application_End sub?
I am not sure exactly how making a "page call" from within that sub is
accomplished. Also what will happen if there is no user logged in to the
server console and therefore no user interface.

I want to avoid writing a Windows service to accomplish this task.

So, the base question is, how can I keep my application "live" and ready for
action?
Is the global.asax a good place to accomplish that?

If someone could point me to a good article on this, hopefully with an
example, I would be appreciate it.

Thanks...

 

[Mark Fitzpatrick]

No. the Global.asax is not a good place. Best thing to do is use something
like a monitoring service to watch your site. This does two things, 1) it
can keep your application in an active state longer, 2) it can help you to
determine when there are problems with your site because of an application
or server issue.

You also don't necessarily need to write a windows server. You could always
write a small console app that you can fire off from a windows task.

Keep in mind, what you want to do will not lead to a healthy server overall.
the application needs to recycle and you could be causing problems for the
web server itself if the application isn't being unloaded naturaly and
things such as database connections and memory recycled.

If the first visit is taking longer than 10 seconds, look to see where you
could trim things down. maybe you're instantiating object in the application
or session start that could be avoided. Make sure the application isn't
being compiled or set in the web.config to debug mode as that will be a
large hit in performance.

Hope this helps,
Mark Fitzpatrick

 

[John Kotuby]

Thanks for your insights Mark.
I will first see if I can "trim the fat" from application startup.