[wp-hackers] Caching as part of the core

[Bryan Petty]

On 07/23/2012 12:25 PM, Michael Van Winkle wrote:
> However, I'm not sure I understand why the existing object cache is 
> insufficient for delivering that fragment. Can we get more specific
> about what the failure of the current object caching api is? I think
> a MUCH bigger issue is theme/plugin developers generally lack of
> awareness and/or concern for caching and performance.

Personally, I believe the failure is mainly in the fact that the
existing object cache isn't persistent. A cache that doesn't have the
ability to persist across requests is really just a glorified static
class variable / global variable. It doesn't actually provide anything
helpful that you couldn't already do without it.

Of course fixing that does absolutely require an outside service such as
memcache/XCache/APC, or just fall back on file. There's two main
arguments I keep seeing against expanding the existing object cache to
support these:

1. Most shared hosting providers don't supply any of those services.
2. This should be implemented by plugins (and is currently).

At Bluehost, even though we don't offer memcache directly, a number of
customers have still compiled and run it themselves on our servers
anyway (and we do enable the PHP memcache extension). On the other hand
though, nearly every shared hosting provider does support file write
permissions, so at the very least, the file cache backend would work out
of the box on 99% of shared hosting accounts.

Putting that aside, it's possible to not only enable support for all of
the backends mentioned above in core WP, but to do so in a completely
backwards compatible way with the existing object cache, *and* also do
so without adding a single extra option to the installer *or* the
administration panel.

Those on shared hosting providers without support for any of those
backends (including file cache, assuming no write permissions)
wouldn't even notice support for this was added. And for those that do
support it, it could either be automatically configured during install
(though I wouldn't recommend that - beyond enabling the file cache at
least), or it could be a couple incredibly simple options in
wp-config.php (as opposed to looking for and installing some possibly
defective/dangerous 3rd party plugin/drop-in).

All web application frameworks provide this API exactly as I described
here and they do it because most web applications need it, and while
WordPress isn't trying to be a web application framework, it's not built
on top of one, so it has to provide it's own. I do actually believe that
this doesn't belong in WordPress, but that's only because it belongs in
a web framework. It's not like WordPress will ever be built on one
though, so there's really not much choice than to add it.

As for implementing it in a plugin, is there really more than one way to
write an API around a cache engine? There really isn't, they're all the
same, they just store the objects in different ways. So what is the
point of it even being a 3rd party drop-in or plugin?

To get back to your concern that the main issue is a lack of awareness
for caching or performance, I think part of that also has to do with the
fact that the existing object cache is barely helpful in the first place
because it's not persistent. When plugin authors know they can cache
data for longer than a single request (and that it will work on nearly
all WP installations by default without requiring additional plugins),
they'll be much more likely to make use of the caching engine since it
will actually make way more of a difference.

-- 
Bryan Petty
WordPress Developer
bpetty at bluehost.com