[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     |     Focuses:  performance
--------------------------+-----------------------------

Comment (by owi):

 Replying to [comment:5 nickchomey]:
 > Perhaps I'm missing something fundamental, but it seems to me that (at
 least part of) the conversation here and in #57625 is focusing on the
 wrong thing - largely how the cache is configured. Specifically, focusing
 on cache key TTL rather than having an appropriate cache eviction policy
 for the cache data (e.g. LRU, which I believe is the default for Redis).
 https://redis.io/docs/reference/eviction/
 >
 As I was the original poster of the aforementioend ticket I wanted to
 clarify (if it was not clear from my description) that I had custom TTL
 for the `query` cache groups (24-72h) and eviction policy - and this did
 the job for me.

 Nevertheless I still believed that the way Core handles keys for these
 groups was not proper. On busy sites the last_updated could be regenerated
 tens or hundreds of times per day (as I proved in original post - it was
 enough to open add new post screen to just regenerate it twice, without
 even clicking save). That could case the numbers of query cache keys grow
 crazy fast and then TTL would be just some magic number which you can set
 based on some trial and error (to balance the cache efficiency vs memory
 levels).

 Also I think (that's my personal opinion) that operating on the redis max
 memory all the time and relying on the eviction is not a healthy state and
 that's just covering the problem.


 All of the above doesn't change the fact that I understand that the
 problem is not trivial to solve and query caches nature make it more
 difficult :)

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