ASP.NET performance issue

[Paul King]

Hi all,

I have written a very simple ASP.NET page on my website that displays the
results of wedding fayres based on the Venue Name selected by the user.

However, when the ASP page loads for the 1st time, this takes quite a long
while to appear (approx 15-20secs). I understand that the ASP has to
generate a process to the IIS server, but is there anyway to speed this
initial process up?

Any help would be great.

Thanks
Paul

 

[Cowboy \(Gregory A. Beamer\) [MVP]]

The issue is the JIT compilation. IN 1.0, without rearchitecting, you have
to hit the page once before your users do. In 2.0, you can precompile, but
you will not have that capability, officially, until 2005. For assemblies
other than the web app itself, you can ngen, which will make native
binaries, avoiding JIT compilation on those assemblies.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

************************************************
Think Outside the Box!
************************************************

 

[Paul King]

Er.. Whatchawhaddawho?

Your speaking to a person whom just picked up a programming ASP.NET in
VB.net book - not a technical architect.

Are you saying in a nutshell that the code cannot be automatically compiled
before the user hits that page?

Paul.

 

[Craig Deelsnyder]

Hi all,

I have written a very simple ASP.NET page on my website that displays the
results of wedding fayres based on the Venue Name selected by the user.

However, when the ASP page loads for the 1st time, this takes quite a long
while to appear (approx 15-20secs). I understand that the ASP has to
generate a process to the IIS server, but is there anyway to speed this
initial process up?

Any help would be great.

Thanks
Paul

Sort of a workaround you can use before 2.0 gets here is an approach
Paul Wilson first shared. Someone took his example and made WebToucher,
a HTTPModule that helps by compiling all files when the first page is
hit (unfortunately the very 1st page hit is still needed):

http://www.xmlwebservices.cc/index_Samples.htm

see the link to Paul's article in there...

 

[Paul King]

Thanks Craig - just what I needed

Bit of a bummer that ASP.NET 1 doesn't do this.

 

[Kevin Spencer]

Your speaking to a person whom just picked up a programming ASP.NET in

VB.net book - not a technical architect.

Are you saying in a nutshell that the code cannot be automatically compiled
before the user hits that page?

In a nutshell, yes. However, you will have to become a "technical architect"
before you can understand why. For now, "Always trust content from
Microsoft." ;-)

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

 

[darrel]

Are you saying in a nutshell that the code cannot be automatically
compiled

before the user hits that page?

I'm not an expert, but this is how I understand it:

If you are using code behind and building compilled DLLs and publishing the
site via that method, then yes, those are all precompiled.

If, on the other hand, you are using inline vb.net on the ASPX pages and/or
using SRC files (instead of codebehind files) then the server needs to
compile it the first time the page is requested, and then caches it
thereafter.

Now, my first 'if' may be incorrect (about dll's already being pre-compiled)
so someone please correct me if I am wrong on that one.

-Darrel

 

[Paul King]

Loud and clear Kevin. I will leave Microsoft for the cleaver stuff

 

[Craig Deelsnyder]

I'm not an expert, but this is how I understand it:

If you are using code behind and building compilled DLLs and publishing the
site via that method, then yes, those are all precompiled.

If, on the other hand, you are using inline vb.net on the ASPX pages and/or
using SRC files (instead of codebehind files) then the server needs to
compile it the first time the page is requested, and then caches it
thereafter.

Now, my first 'if' may be incorrect (about dll's already being pre-compiled)
so someone please correct me if I am wrong on that one.

-Darrel

Well, it's a little confusing, what you're saying is of course
technically correct, you (usually) are creating dll files, which are
called compiled code. However, the webserver itself also does some
loading/compiling itself, when things are called. The most common
example is that all .aspx files are converted into classes at runtime
(the page's rendering, creating of controls, etc. is all created behind
the scenes), and those are then compiled inside the webserver's memory
(the aspnet process). They're kept there until the app comes down or is
recycled.

 

[Craig Deelsnyder]

Thanks Craig - just what I needed

Bit of a bummer that ASP.NET 1 doesn't do this.

Paul King wrote:


the

long


Sort of a workaround you can use before 2.0 gets here is an approach
Paul Wilson first shared. Someone took his example and made WebToucher,
a HTTPModule that helps by compiling all files when the first page is
hit (unfortunately the very 1st page hit is still needed):

http://www.xmlwebservices.cc/index_Samples.htm

see the link to Paul's article in there...

The only thing is (in case you didn't catch it) is that the very first
hit to any page once your app is up will still have this delay as
everything is compiled; that's what I mean by 'very 1st page hit is
needed'. The advantage is that it's not the 1st hit of EVERY page via
the browser. But I would verify that this module does the rest of the
files asynchronously, which I would hope but haven't looked at.
Otherwise your very 1st guy coming in has to wait for the whole site to
compile....so then you'd have to weigh which is worse by testing the
delays....

 

[Craig Deelsnyder]

Thanks Craig - just what I needed

Bit of a bummer that ASP.NET 1 doesn't do this.



The only thing is (in case you didn't catch it) is that the very first
hit to any page once your app is up will still have this delay as
everything is compiled; that's what I mean by 'very 1st page hit is
needed'. The advantage is that it's not the 1st hit of EVERY page via
the browser. But I would verify that this module does the rest of the
files asynchronously, which I would hope but haven't looked at.
Otherwise your very 1st guy coming in has to wait for the whole site to
compile....so then you'd have to weigh which is worse by testing the
delays....

Looks like it may be alright, they're doing a BeginGetResponse which is
asynchronous...whew! But the very 1st site hit will have just a little
extra code as the directories are searched and responses are spawned
off. I thought that would be an intuitive design decision, but you
never know!

Perhaps Paul's article shared that approach as well; it's been awhile
since I looked at this.

 

[Cowboy \(Gregory A. Beamer\) [MVP]]

Apologies for flying so high. I have done .NET so long (since 2000, so I
guess not SO long) that I often forget that the topics I now find simple are
not so simple. I will back up a bit and cover the info a bit better. If I am
still flying too high, just ask questions. Unlike Mr. Spencer, I already ate
today, so I am unlikely to take a chomp in the wrong places.

-----------------------------
NOTE: I know Kevin well, and have the utmost respect for his skill. As such,
I will undoubtably be zinged for that comment. Despite being testy at times,
he is a nice guy.
-----------------------------

There are a couple of ways to architect an application. The first is flat,
where all of the code is in a single ASP .NET project. The second is to move
code that does not directly affect what is painted in the browser to other
projects. Most typically, you see people moving data code to data projects
and business rules code to another project.

In the three-tier (or n-tier) approach, you compile the business and data
projects separately from the web application. In this model, you can create
a strong name using the command line tool sn.exe from a .NET command prompt.
You then can use the strong name key and run ngen.exe to create native
binaries.

Another step back, just to be safe. The difference between .NET compiled
software and ngen'ed software is the .NET stuff still has to be JIT compiled
to run. What this means is your building creates a type of code that can be
run on any machine with .NET (Windows, BSD and Linux). The code is compiled
for the particular OS when it is first run, thus JIT (or Just In Time). When
you run ngen.exe, you make a piece of software that has already run through
the JIT compile and talks in the language of the particular OS it is running
on. No 15 second JIT compile any more.

There is a tool called nAnt, which is worthy of learning.
http://sourceforge.net/projects/nant/

nAnt can precompile your non-Ngened projects by running a simple tool. It is
not the easiest to learn, but it is worthwhile if you have lots of code in
your ASP.NET page and cannot stand a 15-210 second initial hit when it is
JIT compiled.

When the next version of .NET comes out in 2005, you will have the ability
to easily precompile complete applications. I wish the feature was available
today, but it is not. I use nAnt myself, although I have also been known to
set up WAST (the Web Applications Stress Tool - a free download available
from Microsoft at one time, do a search). I set it up a test that hits each
page and set it up for a very short time forcing compile). Another cheap way
to compile everything is to set up a frameset with all of the pages in it.
Put it on your local box. When you stick a new build on the server, hit the
frameset once. Everything builds and your customers get quick response
times.

There is one other way to reduce the hit, if the code branches. What I mean
is something like:

A. If I hit the page and I am not logged in, it runs routine A
B. If I am logged in, it runs routine B

On the first hit, the Page_Load event, along with routine A are compiled,
but you do not take a hit for B. Then, you take a small hit for B only when
you log in. To take advantage of this type of compilation, you still have to
divide out the code, which is a bit more advanced. If you are going to this
degree, you might as well divide into separate projects.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

************************************************
Think Outside the Box!
************************************************

 

[Cowboy \(Gregory A. Beamer\) [MVP]]

Not quite, but close.

In the ASP.NET application, there is no easy way to precompile the
application under 1.0 and 1.1. Under 2.0, the story changes, but we have to
wait a year for that.

If you put portions of your application in other projects (business layer
and data), you can compile those portions and link the ASP.NET app to the
compiled versions. To reduce the compile hit, you can use the tool called
ngen.exe to make native images for your business and data projects, reducing
the overall compile hit. The more code you move to business and data, the
less of a hit.

There is still a bit of overhead in ngen.exe, but it is very small.

There are other ways to reduce JIT load, but tiering the app is the best
model. A huge Page_Load event is almost surely a sign of death when it comes
to load times. It is generally a bad architectural decision, as well.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

************************************************
Think Outside the Box!
************************************************

 

[Cowboy \(Gregory A. Beamer\) [MVP]]

Definite bummer for ASP.NET 1.0.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

************************************************
Think Outside the Box!
************************************************

Thanks Craig - just what I needed

Bit of a bummer that ASP.NET 1 doesn't do this.

 

[Kevin Spencer]

No zinging from me, Greg.

Jus to clarify, I wasn't trying to be testy, and hope that Paul didn't take
offense. I took note that he mentioned his newness to the technology, and
when it comes down to explaining JIT compiling, and the whys and wherefores
of it, it seemed that it would be best to simply give him the "nutshell" he
asked for. The other part was a quote of the famous ActiveX Dialog that you
can check all day long and still see it when a Microsoft ActiveX control
wants to install itself.

The bottom line is, yes, it takes a long time for the first request of the
app to load, but ASP.Net is designed to work in a web server with many
requests coming in, and the trade-off is that any future requests don't
require re-compiling. So, while it may be disconcerting to a newcomer to see
how long the debugger takes to display your work, the end-users won't have
that experience (except for the first one to request a page and start the
application). So, I felt it was best to simply counsel Paul not to worry
about it.

Perhaps my sense of humor was a bit off "colour." If so, I apologize. ;-)

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

 

[darrel]

There are other ways to reduce JIT load, but tiering the app is the best

model. A huge Page_Load event is almost surely a sign of death when it comes
to load times. It is generally a bad architectural decision, as well.

That's good advice for a newbie like me. Thanks!

-Darrel

 

[Cowboy \(Gregory A. Beamer\) [MVP]]

Another thing that is disconcerting to newbies is the memory situation.
Coming from COM, many think that .NET is leaking when it eats up memory. Not
understanding the garbage collection, many freak about the memory use, not
realizing .NET will handle the memory if other apps needs some.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

************************************************
Think Outside the Box!
************************************************

 

[Scott Allen]

This has become an interesting discussion, but I don't think anyone is
making a strong distinction between JIT compiling and the batch
compilation of the ASPX pages themselves.

JIT compiling is the process of turning intermediate language into CPU
specific code.

Batch compiling of ASPX files occurs the first time a request hits a
directory of ASPX files. All the ASPX pages in the directory are
parsed and the runtime launches a C# or VB.NET compiler to generate an
assembly. Sometimes two or three assemblies if the dependencies are
just right.

Since batch compiling happens on a directory by directory basis, it
means you are not necessarily home free after the first request to the
application if you have a subdirectory with a large number of aspx /
ascx files.

Of the two (JIT and batch), I suspect batch compiling is really the
phase which is chewing up time and resources, but I offer no proof.
However, the precompilation in VS2005 isn't going to be an ngen type
precompilation, it's going to remove the overhead of the batch
compilation. The assemblies will still need to be JITted when
execution reaches the code, but the initial performance hit is much
smaller.