Monday, 28 June, 2004
Well i'm nearly 21. Another year has nearly come to pass as does another month. This time last year I was getting philosophical about leaving my teens behind.. this year I don't care. Don't get me wrong, being 20 has rocked in a number of ways but I'm kinda glad to have left those years behind. I look forward to adult life..
To be honest i'm a bit bored of writing about me. I've written about me for a year and a half and it's getting old. That's why i'm writing more topical stuff. This blog gets 200 hits a day (I don't know why) - I'm guessin most of those dudes are geeks so i'm gonna write for them since they're my main readers.
So what is there to write about? Page caching. Page caching is sexy.. well caching in general is. Why you might ask? Cause it allows one to scale your web applications a lot more than you otherwise would be able to.
Take this blog entry for example. This entry is loaded out of the same SQL Server table each time you view it. It takes about a 15th of a second to process this page. This is okay if your a lowly blog writer like myself but what happens if you write something unusually insightful or just plain witty and you end up on slashdot. Your traffic jumps from 200 hits a day to 20 hits a second.
That's a key problem with the web. It's a multiuser system and your traffic can do crazy things like that. The bottom is that your blog should be able to take a load that large. If it can't, then there's a design problem. What we're trying to achieve is a balance between the flexibility of database driven content with the speed that you get from static HTML pages.
In a simple test with my blog page using Softwing ASP profiler I found that caching improved performance by approximately ten times. To put this in perspective the 20 pages per second this site can currently manage turns into 200 when utilising caching. A figure that is easily enough to avoid a good slashdotting.
So hows it done? My weapon of choice is the Application object. There is a culture in ASP development of distain for the Application and Session objects however I feel that in this case their use is justified. The performance increase is so huge that the small amounts of memory taken by each page is a tiny price to pay considering how much CPU time it saves you.
When an incoming request for your blog page arrives the first thing you do is check to see if a cached copy exists in the Application object. If it does, then Response.Write out the stored page. If not, ask the database for a copy to write out and then save that in the Application object for the next page request. Be sure to remember to clear the cache for the most recent blog entry when you add a new blog post and that's all there is to it.
In a later entry I'll guide you guys through an example using ASP.NET. The Caching options in there are a lot more interesting and warrent explanation 
!
For the mean-time, that's all folks.
Simon