Caching Result Sets in PHP: A Content-Change Triggered Caching System

Introduction

Welcome to the second part of the series “Caching result sets in PHP.” Over the first part of the series, we discussed the benefits of having a result set caching system working on the backend, as an efficient mechanism to reduce the overhead caused to the server, particularly when it’s serving many requests from a database-driven application.

Indeed, the result set caching approximation presents some significant advantages over (X)HTML output caching, since it allows for performing some kind of post processing on the cached data, due to the inherent advantage of having the data completely isolated from the (X)HTML structure. This method differs significantly from the conventional “entire-output” caching, which offers a minor level of flexibility.

As with many issues within the context of PHP application acceleration, caching offers a wide range of implementations. Whatever caching system will be applied, its triggering mechanism is mostly based on three possible categories:

• Time expiry based caching triggering
• Content change based caching triggering
• Manually based caching triggering

Of course, an application might use either one of these caching triggers, or a combination of them, because of the flexibility that result set caching brings to developers.

Stepping back to the first part of the series, we’ve looked at a caching script that falls under the first category, that is, triggered by a time expiry condition (usually specified in seconds), thereby forcing a new cache generation each time this condition is met.

Due mainly to the flexible nature of the generated source code, in this second part, we’ll take a look at an application that triggers the caching mechanism based on a content change condition, without modifying its core logic.

So, it looks like we need to write a bit more code. Let’s do it together.