[buddypress-trac] [BuddyPress Trac] #5362: many, many unnecessary queries when BP initializes

[buddypress-trac]

#5362: many, many unnecessary queries when BP initializes
-------------------------------+-----------------------------
 Reporter:  Denis-de-Bernardy  |      Owner:
     Type:  defect (bug)       |     Status:  new
 Priority:  normal             |  Milestone:  Awaiting Review
Component:  Core               |    Version:  1.9.1
 Severity:  normal             |   Keywords:
-------------------------------+-----------------------------
 While probing into what was throwing queries all over the place on my dev
 site (WPMU w/ two sites, a blank theme, BP, and an object-cache), I noted
 unnecessary queries getting thrown absolutely all over the place.

 To see them, add a mu-plugin with the following code:

 {{{
 add_action('shutdown', function() {
     global $wpdb;
     if (defined('SAVEQUERIES') && SAVEQUERIES) var_dump($wpdb->queries);
 }, 1000);
 }}}

 For instance, some of them get thrown multiple times on the same page, e.g
 this one on the secondary site could probably use calls to wp_cache_get():

 {{{
 SELECT * FROM wp_blogs WHERE blog_id = 1 /* get_blog_details */
 }}}

 This one gets run each and every time on a static front page, and should
 likely get ignored altogether (since it's a static front page that should
 theoretically never correspond to a BP page) or cached:

 {{{
 SELECT * FROM wp_users WHERE user_nicename = 'home'
 }}}

 I'd advise that the above also hints at a potential security problem if a
 user can potentially register with a matching username: could his profile
 take over the front page on a site with a static front page that is
 configured with BP_ENABLE_ROOT_PROFILES set to true?

 These get done over and over on every page load. They could probably be
 cached too:

 {{{
 SELECT ID, post_name, post_parent, post_title FROM wp_posts WHERE ID IN
 (9,10) AND post_status = 'publish'
 SELECT * FROM wp_bp_notifications WHERE user_id IN (1) AND component_name
 IN ('activity') AND is_new = 1
 }}}

 Same for notifications. memcache increment (new notifications)/delete
 (notifications read) might be a good idea here to avoid the query
 altogether:

 {{{
 SELECT * FROM wp_bp_notifications WHERE user_id IN (1) AND component_name
 IN ('activity') AND is_new = 1
 }}}


 The last three on the secondary site give me the impression that the
 last_activity user_meta is updated on every page load. This really should
 be throttled somewhat:

 {{{
 SELECT umeta_id FROM wp_usermeta WHERE meta_key = 'last_activity' AND
 user_id = 1
 UPDATE `wp_usermeta` SET `meta_value` = '2014-01-30 17:59:50' WHERE
 `user_id` = 1 AND `meta_key` = 'last_activity'
 SELECT user_id, meta_key, meta_value FROM wp_usermeta WHERE user_id IN (1)
 ORDER BY umeta_id ASC
 }}}

 On the primary site, there's an obvious missed opportunity to use wp_cache
 here:

 {{{
 SELECT meta_key AS name, meta_value AS value FROM wp_sitemeta WHERE
 meta_key IN ( 'tags_blog_id', 'sitewide_tags_blog', 'registration',
 'fileupload_maxk' ) AND site_id = 1
 }}}

 Not sure what this one is supposed to do (it runs on both sites):

 {{{
 SELECT option_name AS name, option_value AS value FROM wp_options WHERE
 option_name IN ( 'bp-deactivated-components', 'bb-config-location', 'bp-
 xprofile-base-group-name', 'bp-xprofile-fullname-field-name', 'bp-blogs-
 first-install', 'bp-disable-profile-sync', 'hide-loggedout-adminbar', 'bp-
 disable-avatar-uploads', 'bp-disable-account-deletion', 'bp-disable-
 blogforum-comments', '_bp_theme_package_id', 'bp_restrict_group_creation',
 '_bp_enable_akismet', '_bp_force_buddybar', 'registration',
 'avatar_default
 }}}

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5362>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac