This was not an easy lesson to learn. Our site is less than a few weeks old and I had figured that it would not receive any large traffic for a few months. I was wrong. As some of you noticed our site hit the viral level with our article about web terms. The amount of traffic that was sent our way crippled our server and taught me the importance of caching mechanisms.

For those unfamiliar with caching, it is a rather simple concept. Caching takes dynamic content and then creates a temporary reserve of that information. That temporary content is then served as static content until it expires. The types of caching mechanisms differentiate on what level they cache the data.

The easiest and most common way to implement caching is to place any non-dynamic content into a static file. In the case of web applications, this is usually an html file. This works excellent for completely static sites, but today’s applications tend to mix dynamic and static content together causing some problems. A good example is to take a look at our sidebar here at Ri and you will see advertisements from Google. This content is dynamic and changes on each reload. However with any luck this post will not change at all, making it static. Two popular ways to handle this is to either cache on the programming language level or using embedded files.

Both of these have their pitfalls, but they can each be used with great success. Caching at the programming language is the default method for most Ruby and PHP programs. This means that for every request, the language interpreter is loaded and determines if the data is now outdated. Launching the interpreter is an expensive operation, but it ensures that your data is verified each time its viewed. The cost of the interpreter can be reduced if it will be needed throughout the user’s operations on the application. It is the approach of “they will need to launch it sometime” and is a  valid argument if that is the case.

The caching mechanism that Ri now uses is embedded files. That advertisement sidebar is saved into its own javascript file and the static content is placed inside its own html file. Inside the html file there is an include command that forces the javascript to load. If the javascript changes, it will immediately be seen upon the next refresh. This may seem simple, but if your static content does change for any reason (like editing a typo), you are responsible for updating any cached files. Forcing the user, or programmer, to remember to update the cache can be difficult if there are many included files. Rebuilding the cache also tends to be expensive, but can be avoided with good programming practices.

The trade offs between different caching mechanisms may seem small, but picking the correct method will save system resources, time, and money. There is one thing for sure and that is the next time you design an application do not wait to implement caching. Learn from my experience and the minute it is feasible to integrate caching, do it. Any of the above caching methods is much better than none at all.