Upcoming SuperCache-Plus feature. Maybe.
I've been pondering the mysteries of the next version of my SuperCache-Plus WordPress plugin which may include some useful extra functionality. The dilemma is that compared to the existing functionality, it's relatively complicated to use and thus it's relatively easy to make a big mess with it. Thus, it has come to pass that I've written this article about it - to test the level of interest versus the risk of having to deal with a barrage of “Ur shitty plugin broke my blog”.
The basic idea is that instead of just caching each full page, you also cache the bits that fit together to make the page. I'm not talking about query caching or object-caching that already exists in WordPress; I'm talking about the final rendered components of the page like the post and comment text.
None of this is particularly new or exciting - there are loads of sites out there doing it - but I'm unaware of any other attempts to do this with WordPress in a way that's accessible to anyone prepared to devote a bit of brain-power to the process.
To set the scene, let's confine our attention to just two things - the text of the posts and comments. Say we have a post that has 100 comments. What currently happens with SuperCache-Plus when a new comment gets added? Simple - The cached pages with that post_ID get removed from the cache along with any cached pages that have no post_ID. The next request for that page (which is most likely the redirect for whoever posted the comment) must rebuild the page from scratch. The next anonymous request will do the same thing. All the plugins that filter and format your comments will be run to regenerate content that hasn't even changed.
Imagine now a better world where adding that comment only requires that single comment to be rendered and the page gets built from 100 cached comments plus the new one. That's a lot less work and based on my observations so far will never (unlike some other caching strategies) merit a warning that it may make your site slower.
As another example; Consider the archive page /2009/01/. At the time of writing, what appears on that page will be very similar to what's on the page /2009/ and probably the ‘Home’ page too. If the rendered blocks are cached for the first one, then generation of the others that contain those blocks will take less time and effort. Similarly, if some of those are in the category ‘News’ then they can be reused to render the ‘News’ category page. The same applies to users. Currently SuperCache[-Plus] caches a copy of each page for each cookied user and one for anonymous users - With this the work done rendering a page for one user can be reused for others.
Here's what my comment loop in comments.php looks like...
<?php foreach ($comments as $comment) : ?> <?php $context = 'complete'.(current_user_can( 'edit_page', $id ) || current_user_can( 'edit_post', $id )); if(wpscp_cache_begin('comment', $comment->comment_ID, $context)) { ?> blah blah blah... <?php wpscp_comment_text(); ?> blah blah blah... <?php wpscp_cache_end('comment', $comment->comment_ID, $context); } ?> <?php endforeach; ?>
All that we've done is used wpscp_comment_text() instead of comment_text() and enclosed the comment block inside a wpscp_cache_begin / wpscp_cache_end structure. One line changed, three lines added and you've got comment caching that's linked to the SuperCache-Plus intelligent purging. There's a few lines of code to go in the theme's functions.php so that nothing breaks if SuperCache-Plus isn't available and that's about it really.
The above example uses nested caching. The inner text of the comment is always the same (on this site) so using wpscp_comment_text() is fine for that. Each comment block however has a ‘moderate’ link for admin users but not for other users so it needs to be cached with a context. In the example the comment block is cached in two versions, each being built using the inner cached text.
Note that the wpscp_comment_text() function can also take a ‘context’ argument plus all the ones that the standard comment_text() function does and that while the example shows nesting one level deep, there is no technical barrier to nesting deeper than this nor is there any requirement to nest anything at all - the example merely shows the the best way to do it for this site and theme.
Also; wpscp_comment_text() is just shorthand for...
if(wpscp_cache_begin('comment', $comment->comment_ID)) { comment_text(); wpscp_cache_end('comment', $comment->comment_ID); }
...there's nothing special about it.
That example was for an old style (pre 2.7) comment loop - what about the newer style that uses wp_list_comments()? Easy; SuperCache-Plus will provide a custom comment walker that should do the trick. I say ‘should’ since I haven't actually done it yet, but that's a minor detail :\
The post loops are treated in a similar way. Here's the relevant bit of my index.php...
<?php while (have_posts()) : the_post(); ?> <?php $context = 'indextopcomplete'.(current_user_can( 'edit_page', $id ) || current_user_can( 'edit_post', $id )); if(wpscp_cache_begin('post', $id, $context)) { ?> blah blah blah... <?php wpscp_the_content(); ?> blah blah blah... <?php wpscp_cache_end('post', $id, $context); } ?> <?php endwhile; ?>
Unfortunately, doing single.php is a tricky one...
<?php $context = "single{$page}complete".current_user_can( 'edit_post', $id ); if(wpscp_cache_begin('post', $id, $context)) { ?> blah blah blah... <?php wpscp_the_content("single$page"); ?> blah blah blah... <?php wpscp_cache_end('post', $id, $context); } ?>
Scratch that; it was easy after all. We just had to use the page number as part of the context.
The contexts are the reason why this can't all be done automatically. Maybe your posts have adverts injected by a plugin for anonymous users or some content only appears to logged-in users or admins. You know your site and the different ways the content can appear. A context is required for each server-side ‘version’. My index.php example is simple and has a context indextopcomplete1 for admins and indextopcomplete for everyone else.
The great thing about doing this is that the more complicated the site is with respect to preprocessing (plugins and theme code) of posts and comments, the bigger the benefit.
The good news is that it's already running on this site. The eAccelerator implementation seems to be holding up well and the benefits are very noticeable. The purging system is functional but incomplete. so all that remains to do is finish that and then do it all again for XCache, APC and Memcached(x2) - I'm thinking of dropping the Zend-Cache backend since I doubt it ever gets used outside of apps built on the framework. ETA is likely to be a few weeks from now.
Now for the bad news. I doubt very much that I will be implementing this with Disk storage in mind. It's doable, but I don't think it's wise or particularly desirable - there can be hundreds of cached fragments making up a page.
But what, I hear you cry, does having thousands of things in the cache do to performance? Not much it seems - With 1000 cached items in eAccelerator, the time to get the list, go through it fetching every item (5MB total) from the cache and then deleting them is less than 50 milliseconds on my dog slow test server. That's much more work than would occur when some content is changed and the cache needs to be selectively purged. Similarly, I've tested the time to get a cached key from eAccelerator with 50,000 keys cached compared with when only one key is cached. The difference is a few microseconds.
In terms of time and effort. It took me about 10 minutes to modify my theme (including thinking through the required contexts).
I'd welcome feedback and opinions on whether this is worth releasing. It's getting done whether you like it or not, but do you think it sounds like something you would use? Does it seem too complicated? Have I missed something that really needs consideration? What if...?
The End is Just the Beginning
