Woocommerce-admin: Invalidate cache on update via cache version number

[joshuatf]

The current use of wp_cache_get and wp_cache_set will only last the duration of the original request. This means that hitting the API multiple times with the same request won't actually benefit from this caching.

This may be the intended behavior, but since some of these queries are somewhat complex, should we consider setting data in a transient?

This would improve speed quite a bit, but because of how many different queries could be performed, this may result in many transients and possibly better left to third party caching plugins.

[timmyc]

@peterfabian @mikejolley any thoughts here?

[peterfabian]

I agree that there is a potential for some speedup there. E.g. when looking at the dashboard and then into a detailed report, some queries might be the same. We'd need to test this a bit more I think, because currently the cache is not used very much if at all.

I would like to understand how much are queries duplicated in a typical session (whatever we think that is), i.e. what would be the cache hit rate in your view, @joshuatf ?

[timmyc]

Another possible use of this would be in the mobile apps - where due to timeout limitations when using the Jetpack proxy via WPCOM, they could issue a series of stats requests, and if they time out, they could subsequently issue the same request and get a quicker response with a primed cache /cc @astralbodies

[astralbodies]

We'd definitely love to have caching of requests so we can keep polling for results with our five second timeout limitations imposed by other technologies. @mindgraffiti has been looking at the same thing for the Core API.

[psealock]

This would improve speed quite a bit, but because of how many different queries could be performed, this may result in many transients and possibly better left to third party caching plugins.

Considering Mobile's requirements for caching in light of the five second timeout limitations, we can't assume an install will have a persistent object cache mechanism, such as memcached. This leaves use of the Transient API as the only way to ensure caching is available.

[psealock]

Update

A result of a GM discussion - The proposed method will be to establish a cache system whereby updates, such as a new order, invalidates all caches using a cache version number.

When an order updates the database, bump the cache version number. When a request comes in, compare the version number to decide whether or not to read from database or existing cache. This is more performant than simply invalidating the cache, which has a performance cost itself.

[jeffstieler]

A result of a GM discussion - The proposed method will be to establish a cache system whereby updates, such as a new order, invalidates all caches using a cache version number.

When an order updates the database, bump the cache version number. When a request comes in, compare the version number to decide whether or not to read from database or existing cache. This is more performant than simply invalidating the cache, which has a performance cost itself.

How about this for implementation:

1. Switch to using the transients API instead of object cache directly
2. Create a new option representing cache version
3. Use cache version in cache keys (forcing a miss after incrementing)
4. Increment cache version whenever a lookup table is updated

[psealock]

1. Switch to using the transients API instead of object cache directly

Do you mean storing DB query results in the transients API instead of object cache? If so, would that be for performance benefits for those who don't have memcached installed?

[jeffstieler]

Do you mean storing DB query results in the transients API instead of object cache?

Yes.

If so, would that be for performance benefits for those who don't have memcached installed?

Yep - transients fall back to wp_options table if there is no persistent cache layer.

[rrennick]

How about this for implementation:

What's in the issue description comes from how WC core has implemented invalidating caches in recent caching changes. eg. https://github.com/woocommerce/woocommerce/pull/23546

[jeffstieler]

@rrennick Here's my WIP: https://github.com/woocommerce/woocommerce-admin/compare/add/2020-cache-versioning

[psealock]

Invalidating caches with a simple version bump instead of actually deleting them seems like the right idea here. Using the transients API appears to be a win with the added benefit for those without a persistent cache layer.

I can't think of a reason not to use transients API, but open to thoughts from the team.