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

[Computer Guru]

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.... 

Computer Guru
NeoSmart Technologies
http://neosmart.net/blog/


> -----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
> core?
> 
> 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
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers