Caching and Actually Speeding Things Up

Image by Peter Forret via Flickr

I've ran into many people throughout my career that were under the impression that caching is a cure for cancer, world hunger and global warming. I myself often fall pray to the "just add more memory" approach for solving problems.

Some 5 years ago, while I was working with ASP classic and VB 6 (yes, you are allowed to chuckle now) on my online movie collection, I came up with the idea that nothing actually beats a flat and pre-processed HTML file for speed. I mean, this may seem obvious and no matter how many times I tried to add cache and do all sorts of tricks, nothing would beat a static file. The problem here is that when I suggest this sort of solution, people would almost always answer that "well, we have caching anyway" and that this sort of solution would actually be going backwards.

Now granted, you cannot use static files for most dynamic pages (static != dynamic) and maybe this would never be a real long-term solution, however lets just consider these benchmarks for PHP and Ruby Frameworks. No matter how many different types of caches you apply to your framework, you will never actually beat HTML files or baseline PHP files for that matter. But the point is, that going back to basics beats frameworks by an order of magnitude.

This reminded me of something I wrote a loooong time ago about event-driven publishing, when something is updated in the database, the webpage cache of a website gets regenerated.

This also reminded me about my thoughts about storing conditions in database tables, where you can save pre-processed results to the database to save you re-processing them.

Conclusion

Well, not so much a conclusion, but an option. Consider making the parts of your website that do not change very often, into static files if you are very concerned about speed. Have your system generate these static files every time they need to be updated.