Authenticated User Caching Thoughts From Another CMS

I just wanted to share some technical information about a very different caching scheme, in hopes that someone would be able to make use of the information for Drupal.

First, a brief background: Coalmarch Productions (the company I currently work for) spent its development budget largely on an in-house CMS (CoalEngine, or CE) with performance, SEO, and flexibility as primary goals. This lasted for years with considerable success until Drupal caught up with us, and since CCK, views, and a number of other wonderful modules makes our custom development costs lower than our own system, we now use Drupal almost exclusively for new sites.

Rather than Drupal's node / taxonomy / block / menu system, CE organizes data into "Elements" which are basically nodes and "Pages" (a collection of elements organized into sections, plus a tree structure to determine the URL). Looking at the g.d.o submit discussion page right now, this could potentially be a "Page" with breadcrumb, search box, etc. elements in the Header section, groups blocks on the right in the sidebar section, and the OG form in the body section.

This setup lead naturally into a two-tier caching system: we store a cache for a Page, which is always the same for a given URL and lets us not look up the Element references on every request, and Element caches, which store pre-rendered html for a given element.

When a request is made, the flow looks like this:

• Map URL to a page cache file
• Build page cache and element loaders if they don't exist
• Include page cache file, which outputs the document tag and some very high level structure for sections
• Page cache includes each element's "Loader" file
• The loader file checks to see if the needed element cache exists, and if not, loads the full bootstrap and renders it

When the page cache is created, it also creates element "Loader" files, which are basically mini bootstraps. An element can be set to cache on a location like $_SESSION['userid'], and if that element hasn't been seen by that user yet, it will have to create it. This way we know that the page cache doesn't have to do logic or need the bootstrap, and the element loaders will always exist if the page wants to use the element, so we don't have to do any conditional logic or even load most of the engine until we hit an element that is not cached. Element loaders are never deleted unless the cache location changes (via code change), and then the page caches are blown out as well so that they get remade.

The real strength comes from how elements determine where to cache. If the element always renders the same for everyone, use the default (single-cache location). If it is different per user, for example a login box that says "Welcome, Joe", then you add the user ID string to the cache path. If you want it to cache different per role, then you put the role in the cache path. We also use it for paging system by putting a GET or POST param (carefully) into the cache path, so ?page=1 and ?page=2 can both cache separately but still be shared between all users.

So, the advantages to this system:

• Like block cache, you can render a chunk of html on one page and use the cache on many
• Almost all content is cache-once anyway, and those situations are handled automatically and very fast
• In few situations where we need something different per-user, we specify that it's the case and it both caches right and is about as fast as possible
• Anon users all share the same cache, so they are very fast automatically without having to make a special case for them
• Even requests that are not fully cached are usually 90% cached

This doesn't translate directly to Drupal because there is no real "page" level in the same sense, but I think that node and block caching can still benefit from a similar path mechanism. The block caching goes a long way, but there is still a need for modules like authcache.

I can provide a lot more detail if anyone is interested at all.