Q about ASP speeds

[mpaine]

I just converted lots of ASP to ASP.NET (using ASP2ASPX) and noticed a
drop in rendering speed. For example, one ASP page takes 0.0313s to be
generated while the ASP.NET version takes 0.4842s. Granted they are
both fast but the ASP speeds makes me think ASP object caching is
better/faster (as the SQL is the exactly the same)

Either that or I don't have something setup correctly (yet). ASP
pages use:

Response.Expires = -1
Response.ExpiresAbsolute = strDatabaseTime - 2
Response.AddHeader "pragma","no-cache"
Response.AddHeader "cache-control","private"
Response.CacheControl = "No-Store"

for caching while the ASP.NET pages use:

Response.Expires = CInt(- 1)
Response.AddHeader("pragma", "no-cache")
Response.AddHeader("cache-control", "private")

So both should be re-rendered every hit. Do you have any suggestions
where I could start looking or good tools for profiling the diffs?

Thank you,
Michael

 

[mszanto]

Have you tried disabling the ViewState? If you're converting from
traditional ASP to ASP.NET then its highly unlikely that you have any
need for the ViewState.
I *never* enable ViewState unless absolutely necessary (usually due to
3rd party controls).

Add the following setting to your page heading on the client side or
set it using the properties for the page:

EnableViewState="False"

m

 

[Scott M.]

There is no question that ASP.NET pages have the capabilities to render and
process MUCH faster than "Classic ASP" page BUT these performance
improvements do not come out of the box, you must understand several ASP.NET
topics and use them in conjunction with each other to get maximum
performance. Here are a few topics to look into:

1. All the server-side code you write in .NET is compiled code vs. the
interpreted code of Classic ASP. Compiled code executes faster than
interpreted code, but in ASP.NET, the first caller of a page will experience
a performance DELAY as the .NET code gets compiled by the Just In Time
compiler. To avoid this delay, you can pre-JIT your code using the
"NGen.exe" tool.

2. Since "pragma", "no-cache" is not always honored by clients and
"cache-control","private" only works in SOME proxy server environments, they
are not really a true test of performance. ASP.NET introduces a server-side
"cache" object, which (when used properly) can dramatically improve
performance. There is also an OutputCache that allows for entire pages or
fragments of pages to be cached.

3. Classic ASP provided native objects such as Request, Response, Server,
Session, Application & Error. In .NET, there are over 10,000 native objects
at your disposal. Learning about the Framework Class Library, namespaces
and assemblies will help you find the right object for the right job.

4. Because so much is new and different from Classic ASP, yet some of your
Classic ASP code (and VBScript code) can be ported to ASP.NET and VB.NET,
newcomers to ASP.NET and VB.NET tend to stick with what they know, rather
than take the time to learn the new ways of ASP.NET and VB.NET. It does
take time but, for example, I think it's been about 4 years since I wrote:
Response.anything. Sure, I could still use the Response object, but .NET
provides so many other (and better) mechanisms for rendering to the client,
that there's no need.

The bottom line is that it is completely normal to look at Classic ASP and
ASP.NET and not see any improvement using ASP.NET, but that is simply
because there is much to know about it and when used properly, ASP.NET blows
Classic ASP away every time.

Good luck!

-Scott

 

[mpaine]

Thank you for the suggestions but using:

<%@ Page language = "VB" Explicit="True" EnableViewState="False" %>

didn't speed things up at all..

 

[mpaine]

1. All the server-side code you write in .NET is compiled code vs. the
interpreted code of Classic ASP. Compiled code executes faster than
interpreted code, but in ASP.NET, the first caller of a page will experience
a performance DELAY as the .NET code gets compiled by the Just In Time
compiler. To avoid this delay, you can pre-JIT your code using the
"NGen.exe" tool.

The load times I mentioned doesn't pertain to first-time hits as the
times are the same on subsequent hits. Still, thanks for the NGen.exe
tip!

2. Since "pragma", "no-cache" is not always honored by clients and
"cache-control","private" only works in SOME proxy server environments, they
are not really a true test of performance. ASP.NET introduces a server-side
"cache" object, which (when used properly) can dramatically improve
performance. There is also an OutputCache that allows for entire pages or
fragments of pages to be cached.

I'll look into this.

3. Classic ASP provided native objects such as Request, Response, Server,
Session, Application & Error. In .NET, there are over 10,000 native objects
at your disposal. Learning about the Framework Class Library, namespaces
and assemblies will help you find the right object for the right job.

We are using much of the same code (want to keep it as close as
possible for this first round since I'm dealing with 6 million lines of
ASP). We will definitely explore the .NET libraries (including third
parties such as NHibernate, dotLucene, etc.

4. Because so much is new and different from Classic ASP, yet some of your
Classic ASP code (and VBScript code) can be ported to ASP.NET and VB.NET,
newcomers to ASP.NET and VB.NET tend to stick with what they know, rather
than take the time to learn the new ways of ASP.NET and VB.NET. It does
take time but, for example, I think it's been about 4 years since I wrote:
Response.anything. Sure, I could still use the Response object, but .NET
provides so many other (and better) mechanisms for rendering to the client,
that there's no need.

This will be the challenge, <ASP:Repeater> seems to look very useful
instead of dynamically including code chunks within a VBScript loop
(yuck).

The bottom line is that it is completely normal to look at Classic ASP and
ASP.NET and not see any improvement using ASP.NET, but that is simply
because there is much to know about it and when used properly, ASP.NET blows
Classic ASP away every time.

I do hope so -- it took a month to do the conversion and it will
probably take a year to tweak the rest.

Thank you,
Michael