Make WordPress Core

Opened 4 years ago

Last modified 4 years ago

#49692 new defect (bug)

_prime_post_caches should not do anything if object cache is not running

Reported by: pcfreak30's profile pcfreak30 Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 5.4
Component: Cache API Keywords:
Focuses: performance Cc:


From what I can see


does more harm than good when querying a large set of posts, and using the memory object cache.

There should be a check with


and possibly a filter to override the behavior so this only takes action when object cache is in use.

Change History (2)

#1 @johnjamesjacoby
4 years ago

Comments, Terms, Sites, and Networks will all exhibit exactly the same shortcoming.

In general, querying for a large set of anything should be avoided, because it will not perform very well in most of the popular environments that WordPress is commonly running on.

For the things that WordPress does itself internally, I find that this approach (and these functions) tend to work pretty well.

For large sets of Posts, you can improve performance by opting out of priming Terms and Meta, but that may or may not actually be better or worse depending on several factors, including the environment itself but also what you plan on doing with the Posts and their relative Terms & Meta once you've primed their caches.

Can you explain a bit more about your use-case and findings? Perhaps there are performance improvements that can be made to these approaches, but at a cursory review of them, I'm not seeing anything jump out at me.

#2 @pcfreak30
4 years ago

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.

Note: See TracTickets for help on using tickets.