ASP.NET Application - First load performances (slow)

[Frédéric H]

Hi,

When I access for the first time of the day to an application developped
with .NET 2.0 (SP1) I have

to wait about 30 seconds to get a response. After that the application page
runs quickly (<1 second). After an IISRESET (command) I got the same problem
(first load=slow, after=quick).

I tested that with a simple application that displayed a hello world. So the
test focused on the

server scope and not on SQL server perfs, remote server perfs or something
else.

I have searched over the net for an explanation or to get "best practices"
and I found some advices :
1. Precompile application
(http://msdn.microsoft.com/en-us/library/ms228015.aspx)
2. Set retail="true" in your machine.config
3. Set debug=false in web.config

But nothing can help.

Someone has an idea ?

Config : We use IIS 6.0 / ASP.NET 2.0 / Win 2003 Server R2 / Xeon E5440
2.83Ghz / 3.75RAM

 

[Joy]

Hi,

The first fresh request takes time because when the web page is requested
for the first time the IIS has to prepare the HTTP response and then send it,
however in case of subsequent request this process is by-passed as IIS uses
caching to serve pages that have already been requested once.


regards,
Joy

 

[Frédéric H]

Hi Joy,

Thank you for your answer. But I do not use OutputCache or caching
functionality in this application. So the process have to render the page at
every load (can be tested with displaying current datetime).

It seems that the problem occurs before any line of code is executed...
during the early asp.net life cycle (maybe when an instance of
HttpApplication is created).

I think I should write a custom http module to "trace" events.

 

[Hans Kesting]

Frédéric H formulated the question :

Hi,

When I access for the first time of the day to an application developped
with .NET 2.0 (SP1) I have

to wait about 30 seconds to get a response. After that the application page
runs quickly (<1 second). After an IISRESET (command) I got the same problem
(first load=slow, after=quick).

I tested that with a simple application that displayed a hello world. So the
test focused on the

server scope and not on SQL server perfs, remote server perfs or something
else.

I have searched over the net for an explanation or to get "best practices"
and I found some advices :
1. Precompile application
(http://msdn.microsoft.com/en-us/library/ms228015.aspx)
2. Set retail="true" in your machine.config
3. Set debug=false in web.config

But nothing can help.

Someone has an idea ?

Config : We use IIS 6.0 / ASP.NET 2.0 / Win 2003 Server R2 / Xeon E5440
2.83Ghz / 3.75RAM

When you access a site for the first time, "everything" needs to be
JITted (and maybe even compiled, depending on the type of
installation). You won't have that on subsequent requests.

Hans Kesting

 

[Frédéric H]

Hi Mark,

I try with and without global.asax and I cannot see a difference.

Thank you for your help

 

[Joy]

Hi Frédéric,

IIS has its own cache which is different than ASP.NET's Cache, so even if
you are not using Caching then also IIS will Cache the HTTP Response (after
the first request has hit) for subsequent requests.

Can you please elaborate, what do you intend to do by having HTTP Module in
between?

regards,
Joy

 

[Frédéric H]

Hi Aidy,

That's we have done to "solve" the problem. We have a service like
application that runs on a server, this applications hits one
page/application (useless page like LoadMe.aspx) every 5 minutes. But we have
about 30 web app/server, so it's a bit tricky...

But I cannot imagine that Microsoft does not have a solution, kb, a
configuration to optimize the loading time.

Best regards

 

[Joy]

Hi Frédéric ,

I hope that you are pre-compiling the application.

As for the procompilation, are you doing the precompiling through "Publish
WebSite" option in visual studio 2005? If so, have you choosed to make the
website "updatable" in the publish website's settings? By default, the
publish website will make the website updatable, that means the web pages
and usercontrols' aspx/ascx template file is not precompiled and remain
their original contents. Therefore, at runtime, the first time a page or
usercontrol is requested, the ASP.NET runtime still need to dynamically
compile it , this make the first time load expensive.

If you do not quite care the ability to edit the aspx or ascx file, you can
just precompile the website with "updatable" option unchecked. Thus, all
the aspx /ascx template file are also precompiled(all the assemblies in bin
dir) and at runtime, the ASP.NET runtime can eliminate the first time
dynamic compilation overhead. You can have a test on your side to see
whether this helps.

Let me know if this helps.

regards,
Joy

 

[Frédéric H]

Hi Joy,

The application is already pre-compiled (I tested with "updatable" or not).
I can see a little difference (about 1-2 seconds).

This advice can help but does not solve this problem

 

[Andrew Morton]

When I access for the first time of the day to an application
developped with .NET 2.0 (SP1) I have

to wait about 30 seconds to get a response. After that the
application page runs quickly (<1 second). After an IISRESET
(command) I got the same problem (first load=slow, after=quick).

Someone has an idea ?

That just the way it is: the disk drives may have to spin up, IIS has to
start up a worker process, then it has to just-too-late compile the
application, all before it can start running the app.

The quickest way would be to make the first access about 30 seconds earlier,
e.g. make request /then/ get coffee

Andrew

 

[sopolenius]

Hi Joy,

The application is already pre-compiled (I tested with "updatable" or not).
I can see a little difference (about 1-2 seconds).

This advice can help but does not solve this problem

 

[sopolenius]

Hi,

If you still haven't found the solution.....look at this article:
http://msdn.microsoft.com/en-us/magazine/cc337892.aspx

We had the same problem. Turns out that for Authenticode signed assemblies
some certificate revocation check is made. If the server has no outbound
internet access it just waits.

We put
<configuration>
<runtime>
<generatePublisherEvidence enabled="false"/>
</runtime>
</configuration>

in machine.config and it sped things up.

Regards,
Dobrin