[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]

#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.3
Component:  Users                    |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  early has-patch dev-     |     Focuses:  administration,
  feedback needs-testing             |  multisite, performance
-------------------------------------+-------------------------------------

Comment (by johnjamesjacoby):

 Coming in blind to this issue, the proposed solutions seem somewhat
 compromised and inconsistent. Multisite is already a mess of function
 names, and these new ones don't provide much in the way of obviousness or
 clarity.

 I agree with @flixos90, and do not like `wp_is_large_user_count()` as a
 function name - its intended purpose is not immediately clear without the
 additional context in the comments in this ticket, especially without
 corresponding `wp_is_large_site_count()` and `wp_is_large_network_count()`
 functions to complete the use-case coverage.

 I'm also reluctant to deprecate the `$network_id` parameter in
 `wp_is_large_network()` because its intended purpose is to determine
 whether or not any specific ''network'' is large, either by number of
 sites or users.

 (`_network_` functions should be doing Network things, just like `_site_`
 functions (usually) do Site things.)

 I also do not agree that ''not'' passing a `$network_id` (or using it when
 in single-site) is wrong here. In either case, `get_current_blog_id()` and
 `get_current_network_id()` should be trusted to do their jobs. If they
 can't be, they should be updated to allow them to be.

 I suggest we introduce a new `is_large_install()` function (to use for
 both single-site and multi-site) because that appears to be the metric we
 are trying to gauge here. That would also partner up well with
 `is_subdomain_install()` and friends.

 ----

 Regarding how the counts themselves are updated, Comments sets a precedent
 (as do Term Relationships) with how they defer their counts using
 `wp_defer_comment_counting()`, `wp_update_comment_count()`, and
 `wp_update_comment_count_now()`, and I believe their approaches are as
 sound as any.

 They include queries, caches, and persistent values in the database, all
 relative to their object hierarchy.

 I suggest we go that route for all of these counts instead of reinventing
 this wheel.

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