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

[WordPress Trac]

#57625: WP_Query cache memory leak
--------------------------+------------------------------
 Reporter:  owi           |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Cache API     |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:  performance
--------------------------+------------------------------

Comment (by owi):

 @spacedmonkey I have addressed all of your concerns in my previous
 messages so I am not sure if I should repeat myself in here. If you do not
 mind please reread them to get a better understanding of my position.

 But a short TLDR:
 - eviction is not a solution because we are evicting also a lot of valid
 keys. And when operating around max capacity we are constantly evicting
 "good" keys as well regardless of the policy we use. Its just a choice
 between lesser evil.
 - why infinite or very long TTL is wrong? Assuming no parameters change
 the cache key is just as valid a minute and a month after creation.
 - short lived TTL is just a magic number to try to cover a design issue -
 there is no good number - make it too small then your cache sucks, make it
 too high and you need to evict keys as you max out. And TTL fluctuates
 over time and depends on traffic and other factors.
 - we as WP users we do not store only posts but also for example
 transients. Transients can be leveraged to store things which are
 expensive to compute. Short TTL or eviction makes that less efficient.

 **Regarding turning it off:**
 For myself I have developed a solution where I filter the cache keys and
 when I stumble upon `wp_query` or `get_terms` I just explicitly store them
 with 1-2 day TTL. That is kind of a rotten compromise to have a cookie and
 eat a cookie.


 I am sorry that this sounds harsh but there is a clear flaw in how we
 handle wp_query keys in Core so we need a better solution and not
 questionable workarounds. I understand that this is not something which
 can be quick or easy but definitely we can do better ;)

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