Title photo
frugal technology, simple living and guerrilla large-appliance repair
Sun, 01 Sep 2013

Proposal: A caching addin for Ode

Updated: Question -- Should cached HTML be prioritized over dynamic CGI? (see Discussion and Questions below)

Level of difficulty: High


Over the past few years, there has been a trend away from dynamically delivery blogging systems like WordPress and Ode to static-site generators like Pelican, Nikola, Jekyll/Octopress and others.

Everybody is worried that their potential web host won't support the technologies that create and deliver blogs, such as Perl, Python, Ruby on Rails, Node.js, etc., and that dynamic delivery is "costly" in terms of CPU time on the server and actual financial cost for those resources.

Feeding into this is the worry (real or imagined) that goes something like this:

What if my site is Slashdotted, or somehow gets wildly popular, or I become the toast of the Internet? Will Ode/whatever-I'm-using be able to keep up with my overwhelming popularity?

It's generally assumed that a static HTML site with no dynamic elements will hold up the best under this "I'm so popular, I have to wear shades" scenario.

But in the "real" world, we're not all so darn popular. But we want to be ready. For our moment.

WordPress, which features dynamic delivery via PHP, solves this problem with caching plugins. These plugins generally take PHP requests that have been made in the recent past and turns them into temporarily cached static HTML files on the server. In Ode's case, posts and indexes are delivered via Perl/CGI.

When a "popular" (aka recently requested) query is made for an entry or index, the plugin delivers the static file, potentially reducing overall CPU load for the system and better handling increased traffic for a few of the many entries in the filesystem/database. And since the likelihood of a "Slashdot"-style traffic onslaught being limited to a single entry (or very few entries) is very high, this sort of scenario (caching as HTML of recently popular entries) has a high likelihood of making the overall blog site much more efficient.

An Ode caching addin would probably always create cached versions of the main index page (i.e the Home page) and maybe the page that delivers the second 10 posts.

It would also cache any individual posts or category requests that are made in the course of the blog's operation over a given period of time (say a day, hour, week or ??). The addin would write these "popular" requests as static HTML.

With the caching addin active, a request for any Ode content would go "through" the addin. The addin would check a list of static files it has created. If the request matches, that file would be delivered. If the request does not match, the request would be processed via Perl/CGI, and that CGI output would be cached as HTML and added to the caching addin's list.

The caching addin would "flush" the cached HTML and the list on a periodic basis. This could be accomplished via HTML request with the addin flushing based on pre-set rules, or via a timed interval, with time determined by a request to the server.

Discussion and questions

  • Would a caching addin require more CGI overhead than it would save? (There would still be some CGI required to run the addin and determine whether a request could be delivered via static HTML.)

  • Maybe the caching code and the resulting static HTML files should be "baked in" to Ode a little more than a traditional addin. By this I mean that an initial request for an index or post could immediately check either a list, or the filesystem itself, for static HTML. If that file is not present, the CGI request would be initiated, and the page would be delivered dynamically and subsequently added to the cache. This way, Ode would "favor" the cached HTML and only initiate a "full" CGI request when necessary.