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

Please visit our partners


Windows Technology Windows Technology
15 Seconds
4GuysFromRolla.com
ASP 101
ASP Wire
VB Forums
VB Wire
WinDrivers.com
internet.commerce internet.commerce
Partners & Affiliates














ASP 101 is an
internet.com site
ASP 101 is an internet.com site
IT
Developer
Internet News
Small Business
Personal Technology

Search internet.com
Advertise
Corporate Info
Newsletters
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 @ Microsoft.com
What is Adovbs.inc and Why Do I Need It?
An Overview of ASP.NET

QUICK TIP:
Upgrade to the 5.5 Scripting Engine
Show All Tips >>
ASP 101 RSS Feed ASP 101 Updates


Why Use Time-Based Page Level Caching?

Why Use Time-Based Page Level Caching?

by Jeff Atwood

Pros

  1. Caching is incredibly fast

    The obvious benefit. Serving up static HTML is an order of magnitude (or more) faster than executing a bunch of ASP code. You are providing a "snapshot" of the page to the user, rather than rendering it dynamically each time. The caching is done per-URL... for example, let's pretend this is a page that lists all the company salespeople for different states. The URLs to list the salespeople would look like this:

    http://www.asp101.com/articles/contrib/pagecaching.asp?state=ca
    http://www.asp101.com/articles/contrib/pagecaching.asp?state=nc
    http://www.asp101.com/articles/contrib/pagecaching.asp?state=fl

    In each case the output would be normally generated on the first request, then automatically be cached for the next for 10 minutes. Remember, unique URLs mean unique HTML cache files.

  2. Almost no code changes required

    Only two minor additions to your ASP page are required. A single include, and a single line of code:

    <!--#include file="incCaching.asp"-->
    call subCacheCheck(10)
    

    Any ASP page can be completely and automatically retrofitted with page-level caching using the trivial code above. It's completely backwards compatible!

  3. Low overhead

    This approach is extremely efficient. It requires very little overhead. The only additional costs are per-page as described below.

    • One application variable containing the date the page was last cached;
    • One HTML cache file stored on disk;
    • and an extra computation at page load. But it's an easy, fast one that looks something a bit like this:
      if (date of app var for this page is older than cache minutes) then
        (server.transfer to that HTML file, terminate execution)
      else
        (cache page to HTML file, set the app var date, and proceed normally)
      end if
      

  4. HTML Compression is now possible

    Since static HTML pages are served, they are subject to HTML compression, assuming you have that option selected in IIS properties. And you should! This is a giant performance win for bandwidth-- HTML compression reduces absolute bytes transmitted by about a 5:1 ratio. So a 50k page becomes a 10k page. That is a big big deal on a modem! And even on broadband it's much snappier. Bottom line: bandwidth is expensive and precious, and client/server CPU time is cheap. Plus, the compressed documents are cached, so the minor cost for compression is only paid once, not per retrieval.

    I don't know if any of you have ever tried IIS compression on ASP code, but it screws IE 5.x up royally. I had this enabled under IIS (ASP and HTM compression) but I was forcde to disable ASP part of the compression because the cached *.asp files were preventing refresh of any kind, even with the F5 button. It was ugly. Real ugly. If anyone has successfully enabled compression for ASP content, or knows of a workaround to the problem I've described, please e-mail me! Anyway, another advantage of this approach is that we avoid the ASP compression bug.

    In case you're worried about the compatibility of compression, I can assure you that all modern browsers, even text based ones, support the HTML 1.1 standard, which includes compression.. it's all quite standard and W3C approved , and has been for years. A couple very high traffic sites I frequent tested this and had no problems. After that I had no qualms in enabling it for all my sites. It's damn near a no-brainer.

  5. User-based trigger

    One common approach to pre-rendering pages is to write a script that runs in the background on a server, and dynamically builds the page every 10 minutes. Our approach is an improvement on this, because it renders the page on demand. So the first visitor to hit the URL will trigger the cache HTM file build, then all subsequent hits to that URL (for the next 10 minutes) will automatically and transparently be redirected to the HTML file. If nobody is visiting the page, it doesn't eat up any CPU time!

Cons

  1. Time based "freshness"

    This is strictly a time-based caching method.. the cache "freshness" is determined by its age in minutes, and nothing else. So if you have caching set for 60 minutes (1 hour), then update all your data, the page will stick around for an hour regardless! You may prefer to have the page cache rebuilt when the data actually changes.. in which case you cannot use this approach. Of course, you can always force the cache to be rebuilt manually or avoided altogether by passing in the appropriate parameters with the URL.

    It is possible to come up with a "smarter" page freshness trigger than "how long ago did I last render this page?"; however, those smarter and more complex triggers will also require more work from the programmer!

  2. Some pages must always be dynamic

    Some pages can never be cached, because you absolutely must make sure the user is always seeing the most up to date information possible!

  3. Page Caching may not be the best approach

    The benefits of page-level caching will depend on several factors.

    1. How long does your ASP page take to execute? (longer is better, short is worse)
    2. How many "hits" per day do you expect for the page? (more hits is better, less hits is worse)
    3. How "fresh" does the page need to be for your users? (not very fresh is better, always fresh is worse)

    The answer to these questions will determine whether page caching is useful to you or not. If you have lots of complex ASP pages, tons of page hits, and not a pressing need for up to the second data, that is a good candidate for page caching. Conversely, if you have simple ASP pages, few hits, and must show real-time data to every user, that is a bad candidate for page caching. Most pages will be somewhere in-between these two extremes!

  4. There are other kinds of Caching

    Page-level caching is a form of output caching. It may be more desirable to cache the inputs for the page: the database. There are various methods of caching sql results or even entire tables, but that's outside the scope of this article.

A Real World Example

Let's say you ran a gaming news page like Blue's News. This web page is updated with fresh gaming news about 10 times per day on average. It also has a tremendous traffic level. With a traditional ASP approach, the news page would be generated from the news database every time a user visits the page.

For a heavily trafficed web site like this one, automatic time-based caching makes perfect sense. Even setting the interval as low as 10 minutes could be a big performance win. Let's say you have 30 requests per minute-- about one every two seconds. Without caching, that would result in 300 page renders in that 10 minute period! With caching, you only render the page once, and the next 299 requests will be served up fast, compressible static HTML. And you can add that caching ability automatically, with two lines of code, without changing any of your existing code!

The only downside, of course, is that users may see a 10 minute old version of the page. But considering the sporadic nature of the updates, this is a very small tradeoff. It's unlikely that visitors would be upset by seeing 10 minute old news!

As you can see from this example, caching can improve performance dramatically! And this include makes it easy!

This code has been substantially rewritten and improved, but it is based on work originally done by John Peterson in this article! Thanks John, for coming up with such a cool and clever technique!

Any questions or comments on this code can be directed to me at wumpus@gamebasement.com. Happy coding!

Getting The Code

The code mentioned above can be downloaded from here.


Home |  News |  Samples |  Articles |  Lessons |  Resources |  Forum |  Links |  Search |  Feedback

Internet.com
The Network for Technology Professionals

Search:

About Internet.com

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