[wp-trac] [WordPress Trac] #49692: _prime_post_caches should not do anything if object cache is not running

[WordPress Trac]

#49692: _prime_post_caches should not do anything if object cache is not running
--------------------------+------------------------------
 Reporter:  pcfreak30     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Cache API     |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:  performance
--------------------------+------------------------------

Comment (by pcfreak30):

 Whenever I am doing performance reviews on sites, a common occurrence is
 the cache priming of posts. I can accept grabbing the data to put in
 redis/memcached, and it not repeating for an hour, but I am seeing rather
 large queries taking up significant time to prefetch stuff when the
 simpler queries would probably perform better. This is an observation from
 many sites, over the years.

 However, even for small queries, I do not think it makes sense to do a
 {{{WHERE ID IN()}}}
 and {{{SELECT post_id, meta_key, meta_value FROM  WHERE post_id IN ()}}}


 In all cases. There may be some cases where its practically faster, but it
 also may be redundant and not actually used. You have {{{get_post_meta}}}
 calling {{{update_meta_cache}}} which I could argue could be negative as
 well, fetching all meta, vs one at a time.

 Overall I see the issue becomes that one route won't help the speed of all
 sites, so a filter flag to decide would allow plugins/themes to make that
 call for specific cases/sites. For
 {{{_prime_post_caches}}}, it would mean checking
 {{{wp_using_ext_object_cache}}} as well.

 This applies to the meta API, and the cache priming overall.

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