[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                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:  performance
--------------------------------------+-----------------------------

Comment (by spacedmonkey):

 Thanks for the feedback, @sanchothefat.

 This ticket was created following a discussion with your CTO, @rmccue. The
 remote cache was taken into consideration during its creation.
 Importantly, this patch does not increase the number of cache gets.

 To clarify how the current and proposed approaches work:

 Current Behaviour
         •       WP_Query is called.
         •       A cache lookup is performed, using the last changed value
 in the cache key.
         •       Cache is found.
         •       A post is updated.
         •       Last changed is updated.
         •       A new cache lookup is performed, now using the updated
 last changed value.
         •       Cache is not found (as the key has changed).
         •       A new cache is generated using the new key.

 Proposed Behaviour
         •       WP_Query is called.
         •       A cache lookup is performed, comparing the last changed
 value in memory with the one stored in cache.
         •       Cache is found and deemed valid.
         •       A post is updated.
         •       Last changed is updated.
         •       A second cache lookup is performed, again comparing last
 changed.
         •       Cache is now considered invalid due to the change.
         •       The same cache key is reused and updated with new values.

 Both approaches perform two cache lookups. The only difference lies in the
 second lookup: instead of a cache miss (which requires regenerating and
 storing new data), the proposed method performs an in-memory comparison.
 This is a very lightweight operation, as the cache in question typically
 contains only an array of post IDs—amounting to just a few bytes.

 Moreover, in some caching systems (such as memcached, in my experience), a
 successful cache get is actually faster than a miss.

 While it’s true that the first request in the proposed model may involve
 retrieving slightly more data, the ability to reuse cache keys is a
 significant improvement. It prevents the object cache from being filled
 with stale or rarely-used keys and allows query caches to persist longer,
 improving overall performance and cache efficiency.

 I agree with @tillkruess, that improving database queries and remote
 caches, are out of scope of this discussed ticket and should be discussed
 else. Changing existing queries will be very hard, as these queries have
 filter that have to be maintained.

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