[wp-hackers] Caching in core? (was: Caching in 2.5: anyone has a file-based caching plugin?)

[Thomas Bukowski]

On Mar 23, 2008, at 12:14 PM, Mahmoud Al-Qudsi wrote:

> With regards to the database-based caching... it's hardly worth a  
> project.
> It would take all of an hour to make and test a db-based caching  
> solution (like that used in vBulletin), and simply adding it to wp- 
> includes/cache.php (for the core) or as an extension to the core- 
> caching feature by sticking it in wp-content/object-cache.php.....

I think first and foremost the target audience are the people on  
shared hosts. I'm guessing that db caching could squeeze more  
performance outta vanilla wp than it has now.

I was thinking to cache not just full-html pages, but also serialized  
objects. For some blogs (say, one with some php ad rotating system),  
it would make sense to disable full page caching entirely. Caching  
these objects will require extending the current WP_Cache to allow  
invalidation of groups of objects (i.e., all posts, all comments,  
etc). This is quite a large, large project, actually. Maybe it isn't  
even possible to implement something like this without major breakage;  
perhaps pages have to be specifically marked as 'fullpage cachable'  
and 'object cachable'; unmarked pages would go straight to db.

One potential problem is that many shared hosts have db size limits.  
So the implementation will need to keep track of the entire db size  
and remove less used objects as the cache size gets too big.

It might make sense to build this 'size limiter' into the core, since  
I imagine most caching solutions will want to limit the size of the  
cache - either in memory or on disk. (I'm not sure if memcached deals  
with overflowing caches already?)

Then, to do this we'll need to keep track of cache hits - probably  
should collect all of the hits and commit them to db at shutdown.

I suppose we should keep the per-invocation object cache as is, so we  
don't hit the database more than once for each object.

I also thought that full-page HTML caches would need some special  
handling. If gzip is enabled, we'll want to cache two versions (if  
that is possible and isn't too demanding). Can also tread into WP  
Super cache territory - write to .htaccess and redirect cached pages  
to some separate "wp-fromcache.php" file that will include the bare  
minimum of wp files - just enough to do the one db query for the  
cached page.

If we were to go ahead to build what is really a caching solution into  
wp core, then we have to be very careful where we put all these little  
fiddly features, to minimize wheel reinvention by future cache plugin  
writers.

And, I'm sure there are plenty of places in the WP codebase where more  
caching hooks can be used, etc.

So lots to do, caching-wise. Some of the things above may be braindead  
suggestions, I'm a little sleepy still.

> It's already controlled by the presence of DEFINEs in wp-config.php;  
> but it can easily be switched to an admin-center option.

The admin interface is much lower priority, of course. There's always  
time to write pretty panels.

> Anyway, all this talk has got me convinced that a line of code is  
> worth a thousand painted pictures; so I'll see what I can draft up  
> real quick.

Do share, do share :)