[wp-trac] [WordPress Trac] #40613: Add query cache to WP_User_Query class

[WordPress Trac]

#40613: Add query cache to WP_User_Query class
-------------------------------------+------------------------------
 Reporter:  johnjamesjacoby          |       Owner:
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Users                    |     Version:  3.1
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:  performance
-------------------------------------+------------------------------

Comment (by dd32):

 I have some serious concerns about adding caching here - it seems like
 it's something that for the majority of sites will fall into one of the
 following buckets
  - It's a small site, and `get_users()` is called with the same set of
 simple arguments, resulting in cache hits
  - It's a large site, where `get_users()` is seldom called but when it is
 it's a few simple arguments, resulting in cache hits
  - It's a large site, where `get_users()` is called often, with varied
 arguments (often complex) resulting in many cache misses due to varying
 keys

 For the first two cases, a cache here would be useful, however, I don't
 think they would really need the cache at all.
 The 3rd case is where caching would be thought to be needed, but if the
 query arguments change often then caching wouldn't actually be of benefit.
 If the reasoning for this change is simply to reduce queries, that seems
 like the incorrect way to go, and I'd suggest that looking at what is
 calling `get_users()` often is a better case of a location for the
 caching.

 While we could make the caching for `get_users()` in-memory non-persistent
 (like we do with say `comments` IIRC), I'm not convinced that it'll
 actually help site performance and instead just make this part of the code
 more complex.

 To tack on to @westi's comment though - in-memory non-persistent query
 caching sounds like an interesting approach, and one that i believe some
 DB caching dropins may already do. I'd like to see that built up in a
 plugin myself to see exactly what impact it has on a regular site (and
 then a site which would actually benefit from it) past memory usage - but
 i suspect it wouldn't be of great benefit to the majority of installs (and
 probably a detriment to a lot of them).

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