[wp-trac] [WordPress Trac] #57625: WP_Query cache memory leak

[WordPress Trac]

#57625: WP_Query cache memory leak
-------------------------------------------------+-------------------------
 Reporter:  owi                                  |       Owner:
                                                 |  spacedmonkey
     Type:  enhancement                          |      Status:  closed
 Priority:  normal                               |   Milestone:  6.3
Component:  Cache API                            |     Version:
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  has-patch early commit has-unit-     |     Focuses:
  tests has-dev-note                             |  performance
-------------------------------------------------+-------------------------

Comment (by nickchomey):

 Perhaps I'm missing something fundamental, but it seems to me that the
 conversation here is focusing on the wrong thing - 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/

 If you use something like allkeys-lru, then the only way actively-used
 keys could get evicted is if your cache is too small - a hosting error,
 not WP. If you do want to use TTL/expire on specific keys, then perhaps
 volatile-lru could be used. It seems to me that this decision should be up
 to the site owner, not WP Core.

 Perhaps a solution to whatever the present problems is to give users and
 plugins more control over caching policies such as whether to apply a TTL
 or not to a specific cache key?

 This article from Ruby on Rails goes into detail about using key-based
 cache expiration, so it seems worth reviewing for inspiration.
 https://signalvnoise.com/posts/3113-how-key-based-cache-expiration-works

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