Why a dynamic website with caching is simpler than a baked site

April 15, 2011

In a comment on my first entry in this series, nothings wrote:

And if you're writing from scratch, writing a static baked system is surely easier than writing a dynamic system with caching. So: better performance, and easier to write.

Actually, I disagree about which option is simpler.

First off, I think it's clear that a simple dynamic system without caching is easier to write than a static system. Both systems need something to render pages from content text, templates, and so on, but once the dynamic system has that its job is basically done. Even if you ignore invalidation and tracking dependencies entirely, the static system needs some additional code to walk all pages (and to know what all pages are, something the dynamic system doesn't necessarily need) and deal appropriately with the results.

(The really simple static system generates all pages every time it is run but doesn't bother writing any that are unchanged from the previous pass. This is scalable enough for a small site and sidesteps all issues of tracking what static pages to update when a particular component changes.)

Once you have a basic dynamic system it's fairly easy to start adding caching to it, even well after the initial design was done. The nature of caching means that you can be selective (only adding caching for a few operations to start with) and you don't have to completely implement fully accurate cache invalidation right away. In fact you can tune the balance of cache expiry, cache invalidation, and cache validation differently for different sorts of caches and objects, depending on what's important and what you have time to implement.

By contrast, page invalidation and dependency tracking for static systems is harder and more annoying to implement. The correctness demands are usually higher and you generally need a universal system, because you effectively only have a single 'cache'. If and when you make generated static pages permanent unless invalidated, your correctness requirements ramp up; being absolutely correct is generally quite costly and complex, but sadly it's what you need.

(If you don't make generated static pages permanent, you throw away increasing amounts of CPU power doing pointless page re-renders and you slow down updates of genuinely changed pages. This is especially the case if you use comparable staleness guarantees to the dynamic system case.)


Written on 15 April 2011.
« More on baking websites to static files and speed
Cache validators versus cache invalidation »

These are my WanderingThoughts
(About the blog)

Full index of entries
Recent comments

This is part of CSpace, and is written by ChrisSiebenmann.
Twitter: @thatcks

* * *

Categories: links, linux, programming, python, snark, solaris, spam, sysadmin, tech, unix, web

This is a DWiki.
GettingAround
(Help)

Search:

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Apr 15 00:55:15 2011
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.