[wp-trac] [WordPress Trac] #38741: Introduce the concept of a large site in order to speed up the Users screen when there are many users

WordPress Trac noreply at wordpress.org
Mon Apr 30 10:04:11 UTC 2018


#38741: Introduce the concept of a large site in order to speed up the Users screen
when there are many users
-------------------------+-------------------------------------------------
 Reporter:  johnbillion  |       Owner:  johnbillion
     Type:  enhancement  |      Status:  accepted
 Priority:  normal       |   Milestone:  5.0
Component:  Users        |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  early        |     Focuses:  administration, multisite,
  needs-patch            |  performance
-------------------------+-------------------------------------------------

Comment (by tharsheblows):

 @flixos90 It'd be useful for me to take a step back and clarify what
 `wp_is_large_site('users')` is meant to do – in my mind it's a kill switch
 for functions that are too expensive to run when a table is large, eg
 count_users() on a single site install. In this context only the size of
 the table matters. For example, if a site in a multisite network only has
 10 users but the network has 20,000 then it's not a good idea to run a
 slow query on it.

 My worry is that people will use `wp_is_large_site( 'users' )` as a check
 before running expensive queries on both single site and multisite
 installs when this might not be what they wanted. One possible workaround
 is to use `wp_is_large_network()` as the multisite check for
 `wp_is_large_site('users')` rather than the query on usermeta when it's
 used on multisite and keep the rest the same because those are useful
 functions. Extending to posts and other tables could then be done on a
 site by site basis.

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


More information about the wp-trac mailing list