[wp-hackers] should (can?) wp-cache be adopted into the core?
computerguru at neosmart.net
Tue Apr 17 10:24:13 GMT 2007
You know, with the importance of Caching, I'm surprised the MySQL team
hasn't developed a pure-caching extension for MySQL itself.....
What better place to implement a complete caching layer than at the SQL
backend? Via a nice, powerful, and easy-to-use GUI you can specify exactly
what tables/databases you want cached, how long a cache should last, whether
the results of uncached queries should be written to the hard disk, and so
on and so forth.
Obviously I'm dreaming, but you never know....
> -----Original Message-----
> From: wp-hackers-bounces at lists.automattic.com [mailto:wp-hackers-
> bounces at lists.automattic.com] On Behalf Of Andy Skelton
> Sent: Tuesday, April 17, 2007 10:59 AM
> To: wp-hackers at lists.automattic.com
> Subject: Re: [wp-hackers] should (can?) wp-cache be adopted into the
> 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
> > average shared hosting setup -- though on dedi setups, with APC or
> > memcached and/or php bytecode caching, I could imagine setups where
> > object cache could beat out the wp-cache 'php page' caching system.
> > run on shared for cost+stability management, I'd run on a VPS if my
> > 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
> $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:
> 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
> 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.
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
More information about the wp-hackers