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

WordPress Trac noreply at wordpress.org
Tue Mar 22 17:30:05 UTC 2022


#40613: Add query cache to WP_User_Query class
-------------------------------------+------------------------------
 Reporter:  johnjamesjacoby          |       Owner:  (none)
     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 OllieJones):

 A similar issue crops up in the Gutenberg editor's REST request to
 populate the author dropdown.

 The REST request looks like this

 https://giantsite.example.com/wp-
 json/wp/v2/users?context=view&who=authors&per_page=50&_fields=id,name&_locale=user

 Enhancing its performance requires judicious filtering at the
 `'rest_user_query'` hook.

 (Just like handling the Posts and Pages panels requires judicious
 filtering on `'wp_dropdown_users_args'`.)

 Why are these slow? They need to examine each user's `wp_capabilities`
 metadata, which holds a serialized php object. It's expensive for MariaDB
 / MySQL to filter on this sort of predicate.

     WHERE ... meta_key = 'wp_capabilities' AND meta_value LIKE
 '%"author"%'

 for two reasons. One is the notorious `LIKE '%something'` dbms performance
 killer. The other is the fact that `meta_value` columns are CLOBs, which
 take extra work for the dbms to retrieve. And retrieve them it must, one
 for every user. In a megauser installation, that is *very* slow. It also
 hammers the dbms internal cache, potentially slowing down everything else.

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


More information about the wp-trac mailing list