[wp-hackers] should (can?) wp-cache be adopted into the core?

[Andy Skelton]

On 4/16/07, David Chait <davebytes at comcast.net> wrote:
> Any reasons it shouldn't be in the core (even if it's kept as a
> plugin...), while the object-caching approach IS?  Note that object
> caching has, in the past, shown to be detrimental to performance on the
> average shared hosting setup -- though on dedi setups, with APC or
> memcached and/or php bytecode caching, I could imagine setups where the
> object cache could beat out the wp-cache 'php page' caching system.  I
> run on shared for cost+stability management, I'd run on a VPS if my site
> really took off again.. ;)

I would not like to see WP-Cache bundled with core in its current
state. The object cache has come a long way. The object cache is not a
substitute for WP-Cache, nor vice versa, but they are ignorant of each
other when they should be cooperating or even fusing.

What I want is for WP to have an object cache that is strong enough
that rendered pages could be cached, retrieved, optionally mixed with
dynamic content, served and appropriately invalidated using whatever
object cache client suits the setup.

In order to be compatible with full-page caching, all code (including
themes, plugins, widgets, mods) must comply with several principles of
caching that just haven't been codified yet. So those standards would
have to be written and followed.

That's a lot to ask for, I know, but it would be ideal. Picture this:
you install WordPress, you save a new post with comments off, you
visit the home page and notice that several queries were required in
order to render the page. The next reload should require zero queries.
You should be able to shut down MySQL and have WordPress serve that
same rendered page from cache until the end of time.

I have an experimental memcached client that implements the existing
"group" parameter as more of a "tags" parameter that accepts any
number of symbols indicating which datasets contribute to the cached
object. When an underlying dataset is changed, every object so tagged
can be invalidated by simply flushing the tag for that dataset.

(The dirty work of removing expired items from the cache can be done
by the cache client, the caching layer, or a virtual or actual cleanup
daemon. What matters most is that expired items are never returned by
the cache_get function.)

In this over-simplified example, we just finished rendering a page
that displays posts and comments and depends on some options for
formatting.

$key = md5( $request_uri );
$html = ob_get_contents();
$tags = array('posts', 'comments', 'options');
wp_cache_set( $key, $html, $tags );

Now when we see that same request URI we can serve from the cache:
$key = md5( $request_uri );
if ( $html = wp_cache_get( $key ) )
 die( $html );

(Did you notice that I removed the second parameter to the _get
function? This way you don't need to know the tags to get the data
associated with a key. Groups could be kept as an optional parameter;
this is an over-simplified example.)

The cached object is valid as long as the underlying data is
unchanged. Any function that changes underlying data should do one of
the following:
wp_cache_flush('posts');
wp_cache_flush('comments');
wp_cache_flush('options');
and any one of those flush operations is all that's needed to
invalidate our cached HTML, forcing the next page to render a fresh
page.

An extremely flexible system would permit tag registration by any
function that adds another dataset dependency to the mix. Thus if a
plugin uses data from its own table to contribute to the rendered
page, it should register its own tag on output and handle the flushing
of that tag when the related data is changed. Tag flushing could also
be done at intervals or by a schedule but careful flushing would make
this unnecessary.

In closing, I apologize for the long email and I hope you find some
way to get your ten minutes back.

Andy