[wp-trac] [WordPress Trac] #59592: Store last changed value in key instead of using it as a salt for query caches

[WordPress Trac]

#59592: Store last changed value in key instead of using it as a salt for query
caches
--------------------------+----------------------------
 Reporter:  spacedmonkey  |      Owner:  (none)
     Type:  enhancement   |     Status:  new
 Priority:  normal        |  Milestone:  Future Release
Component:  Cache API     |    Version:
 Severity:  normal        |   Keywords:
  Focuses:  performance   |
--------------------------+----------------------------
 This 'last changed' timestamp serves as a salt, implying that when this
 value changes, the cache key also changes, leading to the creation of a
 new cache. This method of cache invalidation has proven effective over the
 years but presents a drawback – it generates an excessive number of
 caches.

 Imagine a high-traffic website constantly generating new content with new
 posts added every 10 minutes. This results in the 'last changed' cache
 being updated every time a new post or revision is created. Consequently,
 the WP_Query for the homepage could potentially generate a new cache each
 time a post is updated. This could lead to the creation of hundreds or
 even thousands of caches. The concept behind an object cache is to allow
 unused keys to expire and be removed from the cache. However, this process
 is not swift and may take hours or even days for these keys to naturally
 fall out of the cache. Furthermore, there's a risk that the object cache
 could become bloated and remove actively used cache keys.

 The solution lies in reusing cache keys. Instead of using 'last changed'
 as a salt, store the 'last changed' values within the cache value itself.
 Then, retrieve the cache value and compare the 'last changed' value stored
 in the cache with the actual 'last changed' value. If they don't match,
 mark the cache as invalid, retrieve the values from the database, and
 resave the cache with an updated 'last changed' value.

 This approach offers several benefits:

 Cache keys are reused, ensuring that the number of cache queries remains
 stable, and the cache queries clean up after themselves.
 Predictable cache keys allow caches to be primed efficiently. For
 instance, a caching plugin can discern the types of queries on a page and
 prime multiple cache keys in a single request.
 However, there are some downsides to consider:

 Third-party plugins may be reliant on salted cache keys.
 When comparing the last updated value, the entire cache must be retrieved.
 This means that the first user after cache invalidation may experience a
 slightly larger request."

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/59592>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform