[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 rmccue):

 I think I had originally suggested this when chatting with @spacedmonkey
 (although, I'm not the CTO :D), primarily because the introducing of this
 key-based caching started causing cache "churn" for us with data getting
 pushed out of Redis.

 Most of WP is designed ''not'' to use key-based invalidation generally, so
 this was a pretty big conceptual change to the design of the cache system
 as a whole; moving back to regular keying I think makes the most sense and
 keeps it consistent. I can see a case for key-based invalidation, but WP
 was never really designed for that, so switching it has caused some
 issues.

 (For reference, we use allkeys-lfu as the eviction policy.)

 @sanchothefat Note that the data being stored here is only a list of IDs,
 as those then get pushed to `_prime_{post,term,comment}_caches()` and the
 various populate functions - so the typical size here is under a kilobyte.

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