ASP 101 - Active Server Pages 101 - Web01
The Place ASP Developers Go!

Please visit our partners

Windows Technology Windows Technology
15 Seconds
ASP 101
ASP Wire
VB Forums
VB Wire
internet.commerce internet.commerce
Partners & Affiliates

ASP 101 is an site
ASP 101 is an site
Internet News
Small Business
Personal Technology

Corporate Info
Tech Jobs
E-mail Offers

ASP 101 News Flash ASP 101 News Flash

 Top ASP 101 Stories Top ASP 101 Stories
The Top 10 ASP Links @
What is and Why Do I Need It?
An Overview of ASP.NET

Using Access Hyperlink Fields From ASP
Show All Tips >>
ASP 101 RSS Feed ASP 101 Updates

An Overview of ASP.NET - Increased Performance

An Overview of ASP.NET

by John Peterson

Increased Performance

[If you read the last section let me apologize now and say that this one is much more interesting and exciting!]

The one thing you can never have too much of as a programmer (besides caffinee!) is speed! Once you actually get your code working, the next most important thing is almost always getting it to run faster. In ASP you could only tweak your code so far until moving it to a component was the only way to get that last little performance boost. Well you'll be happy to know that this wasn't overlooked when Microsoft built ASP.NET.

ASP.NET code is now compiled.

Let me say that again... ASP.NET code is now compiled! Don't worry... it's not what you think. You don't have to create makefiles and stop and restart things to re-register components. None of it! It just works... you write code just like you always have and yet you still get the benefits of early binding, just-in-time compilation, native optimization, and caching! How is this possible? Well I'm going to tell you!

On it's first request for the script, the runtime compiles the code and keeps a cached copy of the compiled result. This cached copy can then be used whenever there is another request for the script. This results in greatly increased performance because after this first request, the code can run from the much faster compiled version.

The natural question is then "How does it know when I've made changes?" Luckily Microsoft was on top of this one too. The runtime watches the source file on the file system. When the original source file changes, it automatically pulls the compiled version out of the cache so that when the next request comes in it'll be re-compiled. This means we get all the benefits of compiled code and none of the headaches of having to compile it ourselves. It doesn't get much better then that folks! Or does it...


I'm not sure where to put this... it's so important that it could go here or in scalability or in development or even back in infrastructure, but I guess this is as good a place as any so let's get on with it. If you couldn't guess by the heading I'm talking about caching.

One of the common things many developers have found the need to build is some sort of cache in order to speed things up. Whether it's the output of an asp page to an html file, a stock quote that you get from a slow internet link, a recordset of the states and their abbreviations for your shipping forms, or even a database-driven dynamic menu that you've found isn't actually all that dynamic, there are plenty of times when there's no reason to spend the time to get and/or build these things for every client request. Small amounts of data that don't continuously change are actually very common in building web sites, but just because they're not truly dynamic doesn't mean you want to hard code them so where does that leave you? Until now it lefts you building a caching system of some sort.

The basic caching scenario is to first identify the appropriate things to cache. Then you need to place them in an application variable in some form or another. Then your code has to be able to understand this form. Then you've got to determine how long to cache it for and write a routine to clear the cache. But wait... if you clear the cache then the routine that uses it has to know how to repopulate it... and around and around we go.

Well not anymore... a caching system has been built into ASP.NET and since the whole system is more object-oriented then before it makes sense that this caching system caches, you guessed it... objects. So what you're caching looks like it did when you got it when you actually go to use it. You can set up all sorts of conditions on how long to cache things for. You can even link a particular item to a file on the filesystem so that when the file changes the associated item is flushed from the cache!

And that's not all... ASP.NET also does output caching. This is where it takes the result of your ASP.NET script and saves a copy so that when the next person requests it it doesn't ever even have to run... the correct output is waiting to be sent. And it's smart too. It caches based on the querystring so that a page that is passed parameters will only return the cached version if the parameters match the parameters used in the cached version!

Sometimes figuring out what to cache based on your site can be a little tricky, but at least now actually caching it won't be.

The New ASP.NET Infrastructure | Back to the Index | Greater Scalability

Home |  News |  Samples |  Articles |  Lessons |  Resources |  Forum |  Links |  Search |  Feedback
The Network for Technology Professionals



Legal Notices, Licensing, Permissions, Privacy Policy.
Advertise | Newsletters | E-mail Offers