Mitch talks about an article about moving from an IBM Websphere based weather.com to a Linux and open source based environment. He makes a passing comment about cachability, and that caching would improve the performance of the site.
I think that the IT industry has lost something over the last couple of years, and I think it's time for it to come back. That thing is static content. I see no reason that a largely static site such as weather.com (people read the weather, don't change it, and the content updates regularly, but nowhere near as frequently as once per click).
So, why not write an engine to generate the entire content of the site from templates, and then dump the output into a bunch of files on disc to serve? In fact, when you update the data, just change the file on disc and let the new file get served out when it's good and ready. This keeps processor load as low as possible while serving, and in fact probably makes the whole thing easier to debug. It's how my site is done too, and it makes the box that's hosting it much more responsive than it used to be under a dynamic workload.
Everything should be static, unless you can't possibly do it without some runtime code.
Technorati tags for this post: dotnet web dynamic static content
posted at: 16:46 | path: /dotnet | permanent link to this entry
Jason
When I recently checked out starting a blog with blogger.com I noticed that they do this. Rather than pulling blog posts from a database each time a page loads, it rebuilds the static html files whenever the blog owner posts or changes the layout of the blog. Probably a smart idea for the blog system that Google promotes.
Mitch Denny
The problem with that strategy is that as soon as you want _something_ to be dynamic the model starts to fall down. Yes - you can generate dynamic pages with content spliced in but you spend forever compiling on content changes.
I've got a client who is backpeddling from the content splicing model as fast as we can because it doesn't really scale with .NET.