[wp-hackers] Caching as part of the core

[Bryan Petty]

On 07/23/2012 09:20 PM, Dion Hulse (dd32) wrote:
> Back in WordPress < 2.5, there was a file-based Object cache included
> in WordPress by default, however, it suffered one major drawback..
> although when enabled it reduced the reliance upon MySQL and
> regenerating objects constantly, on many hosts it was inefficient and
> would *slow the site down instead*.

That's not a problem with the caching system, it's a problem with code
using the cache improperly, especially since the code using it at the
time did know it was a file backed cache since it always was one before
it was crippled.

Any cache system regardless of where and how it stores the data can
still be highly inefficient and improperly used depending on what is
using it and how. This includes the current non-persistent object cache.

I may be new to the list, but I do know the history here and the reasons
the original file based cache was removed.

By removing it, you solved the performance of poorly written code
without fixing the code in question, while also slowing down other code
that relied on the persistent nature of the cache to store
computationally heavy data that was only ever computed once per request
in the first place, but was still required for a majority of page
requests. Making that change crippled every single plugin providing
page/fragment caching at the time that utilized the old persistent file
cache before it was removed from WordPress. Were any of the 5+ page
caching plugins you mentioned doing this before it was removed? Do you
know their history?

> Filesystems are often not fast, infact, they're REALLY slow, in many
> cases, querying the data directly from MySQL was faster (thanks to
> it's in-memory caches - query cache and table indicies in memory, etc)
> - but a SQL is almost always slower than a key-value lookup in a
> proper memory cache (Since it has to parse the query, check no data
> changed, etc)

Right, and this is why developers should be trained not to use a cache
for data that is already in the database (or should be). It still
doesn't mean that WordPress shouldn't provide a persistent cache for the
developers that know better, and know how to use a file based cache
efficiently.

> It's true that since the file cache was introduced (And later removed)
> that WordPress has become much more complex, the data structures being
> stored are larger, the number of keys being set are larger (as there's
> permutations of data with the number of options we now have for
> functions), so potential issues back then, are perhaps compounded
> today and will be even worse..

You are right, the problem *could* be compounded if the new cache API
I'm proposing is designed incorrectly.

Everything using it right now is expecting it to only store the data in
memory (since that's what it currently does). That doesn't have to
change to add new persistent backends though.

For example, if a cache set is called without an expiration as most
probably do right now (I can only find 3 locations in core that do
specify an expiration), we could assume it remains in the non-persistent
memory cache, while everything else with an expiration is saved in the
persistent cache.

> Full page caching to a static file is significantly different from the
> above scenario, for that, you're storing and retrieving a SINGLE file
> (So even if it's hitting the disk, it isn't loading the 100+ WordPress
> files, nor having to load PHP in some cases). This is significantly
> faster and more efficient *on pretty much all hosts*.
> 
> So, Why not include a full-page cache in WordPress then? Well.. several reasons:
>  1. We have Plugins for this - the fact we have at least 5 different
> plugins which do this in different ways goes to show something: There
> is never a right way, nor a wrong way, every plugin suits different
> use-cases
> 
>  2. Users loose a lot of dynamic abilities in their sites (regardless
> of if you guys don't do that, or know you can use workarounds), face
> it, most sites do NOT need full page caching, I can't count the number
> of *fast* WordPress sites I come across which do not have a caching
> plugin installed.. WordPress isn't as slow as many people like to
> believe
> 
>  3. Not all server configurations are the same, we can't expect
> everyone to be running Apache (Infact, IIS support is going great, and
> looks like nginx support is "getting better"(I'm referring to rewrite
> rule generation for config files here - see trac)), all 3 of these
> major web servers require a different configuration method for direct
> serving of static .html files, and although it can be done within PHP,
> that's still an overhead many people don't want (thus,they use a
> plugin to override it.. etc..)
> 
>  4. Adding it to core requires that it be compatible with many
> configurations, this means often using a slower method if it means
> it's more compatible, plugins don't generally have this problem, and
> can throw a bazillion configuration options in instead..  But it's
> also an extra thing the core team have to support (I can guarantee
> you, If a *basic* file cache was added to WordPress, most of the
> plugin authors who write this stuff would leave it to us to maintain..
>  Keeping caching in a plugin means that updates can be pushed
> separately from WordPress, and is the direction WordPress has been
> going for a long time (Just look at the Debug functionality for
> WordPress for example - It all requires a plugin, same as caching,
> different databases, etc)

So... four reasons not to add a full page cache API to core when I was
only discussing the addition of a persistent cache API. I'm pretty sure
I didn't even mention "page", "partial", "template", or "fragment" once
in my entire email.

Do you even know what I'm proposing? Unlike many others participating in
this thread, at least I know that we can't even begin discussing a
potential page caching API until we actually have a persistent cache to
store it in. I didn't even touch that subject.

Since you brought it up though, maybe we should discuss how developers
can't actually write page caching plugins without writing their own
persistent cache system included in their plugins currently because the
object cache in core has been entirely useless for that since 2008. This
isn't even a question of whether a page caching plugin would use it or
not, *all* page caching plugins require a persistent cache.

-- 
Bryan Petty
WordPress Developer
bpetty at bluehost.com