[wp-hackers] Caching in core? (was: Caching in 2.5: anyone has
a file-based caching plugin?)
wordpress at neodude.net
Sun Mar 23 16:50:46 GMT 2008
On Mar 23, 2008, at 12:14 PM, Mahmoud Al-Qudsi wrote:
> With regards to the database-based caching... it's hardly worth a
> 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
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
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 :)
More information about the wp-hackers