[wp-hackers] Caching as part of the core

[Jeff Waugh]

On Sat, Jul 28, 2012 at 5:43 PM, Mike Schinkel <mike at newclarity.net> wrote:

> > Page caching is too low level to bother about transients or fragments,
> and
> > you're always going to use transients or fragments in the higher level,
> > application logic context of a plugin or theme. That's where they make
> > sense.
>
> I disagree with that, and I don't see any evidence to the contrary.
>
> > You want to get in and out of advanced-cache.php as quickly as possible
> --
> > if at all. The call tree is tiny: wp-config.php -> wp-settings.php (very
> > few files loaded, actions taken prior to...) ->
> > wp-content/advanced-cache.php.
>
> Agreed, with the operative phrase being "as possible."  As quickly as
> possible, but no quicker.  Such as when you need to compose a page from a
>  cached page template merged with fragments.
>

I fully understand the use case you're describing, but that's not what
wp-content/advanced-cache.php is for. It is for complete page caching,
similar to what you might implement outside the application with a reverse
proxy cache. Although you take a performance hit for doing it within the
application, it gives you slightly more flexibility -- you can lean on more
of what the application knows. For instance, wp-super-cache can force a
page cache miss in certain circumstances where a reverse proxy cache might
not (due to lack of info or logic).

> If the advanced-cache implementation in use wants to use the provided
> > object-cache implementation, rock and roll -- it can load it itself (as
> > wp-super-cache does).
>
> I just scanned the code in WP Super Cache and what you said is not true;
> WP Super Cache does not load the provided object-cache implementation,
> which is in /wp-includes/cache.php.
>
> Yes WP Super Cache's /wp-content/advanced-cache.php does call
> /wp-content/object-cache.php, but the latter is also a dropin so you are
> proposing to solve the problem I identified with a solution that has the
> same problematic attributes of the problem identified.
>

A terminology issue: wp-includes/cache.php is for the most part an object
cache *interface* (the implementation of which is only relevant within a
single request), while wp-content/object-cache.php is an implementation.
wp-super-cache doesn't need the interface, it needs the implementation. So,
I do mean the user-provided (persistent) object cache implementation.

(Much of the confusion in this discussion is why I have a picture of
turtles in my WordPress performance presentations... "turtles all the way
down".)

> Themes and plugins can already use transients or the object cache API to
> > cache fragments, while providing their own cache invalidation logic (or
> in
> > the case of transients, timeouts).
>
> Yes but that's irrelevant.  Themes and plugins can't use the existing
> Transients or object cache API in /wp-content/advanced-cache.php if there
> is any chance they won't be able to serve the content and thus must
> continue loading WordPress.  WordPress does a require('
> /wp-includes/cache.php') after it calls /wp-content/advanced-cache.php so
> attempting to load them twice will result in an error.
>

Themes and plugins are (almost) entirely irrelevant at the early stage in
which wp-content/advanced-cache.php kicks in -- that's because it's there
for implementing page caching, which cares not for higher level nonsense
like... themes and plugins. :-)

> A fragment caching API in core would have to consider the many and varied
> > use cases for fragment caching *and* the many and varied strategies for
> > cache invalidation.
>
> No it wouldn't.  It would need only provide a useful implementation that
> covers 20% of the common patterns used 80% of the time, and then be
> hookable so that it can be extended for the many and varied use-cases for
> for fragment caching *and* the many and varied strategies for cache
> invalidation.
>

Dude, APIs are HARD. Caching is HARD. Cache invalidation is HARD. What
you've described in the above paragraph is basically what already exists
with the current transients and object caching APIs. You can build a sweet
fragment cache around those, right now!

BTW, I've heard caching has too many variables but I've yet to see anyone
> give real world use-cases to demonstrate that there are actually too many
> methods and too varied of strategies.  It may be the case, but I've not
> seen any evidence to back up those claims.  Show me how it "can't" be done
> and I'll likely uncover the underly pattern that would enable it to be done.
>

Practical use case for you to chew on: I have a widget that I'd like to
fragment cache, because building it takes a fair amount of time on each
request. It displays thumbnails of images from the 10 most popular posts on
the website, as determined by Google Analytics.

Note: Caching the fragment is "easy". Coming up with a sensible cache
invalidation strategy (that isn't "regenerate it again every five
minutes")... not so much.


> Then why did you decide to argue it hypothetically?  And why the religion
> on this issue? Why get so charged up to defend core against caching yet
> ignore the specifics needed to enable code to be written?
>

It's not religion. It's just difficult stuff that is best demonstrated
outside core before it's brought in.


> 1.) Load the Transients API before advanced-cache.php is called[1]
>

Transients are not useful in the context of (mostly application-logic-free)
full page caching. This might suggest a misunderstanding of page caching,
which hopefully I've explained above.


> 2.) Enable multiple dropin files per type of dropin and enable hooks
> before advanced-cache.php[2]
>

Explain why someone would want multiple implementations of page or object
caching, and what kind of logic would be used to choose between them.


> 3.) Address this fragment caching ticket[3]
>

I agree that a fragment caching API would be really cool [1]. But it can be
implemented and demonstrated long before it needs to be proposed for core
or accepted as the divine strategy of the project.

[1] In fact, if the API also allowed you to fetch fragments independently,
it'd be a really helpful way to make ESI easier. That's a pretty hard-core
niche interest, though. :-)