Opened 11 years ago
Closed 11 years ago
#5362 closed defect (bug) (fixed)
Utilize caching during BP init process
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | 2.0 | Priority: | normal |
Severity: | normal | Version: | 1.9.1 |
Component: | Core | Keywords: | |
Cc: | ddebernardy@… |
Description
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
Thanks for the details, Denis-de-Bernardy.
All the queries you mention here are necessary for BuddyPress to function, though you are correct that all of them should be aggressively cached. Persistent caching has not been a focus for BP in the past, but it's something that we are planning to pursue vigorously starting with this development cycle. See eg #5350. I'll move this ticket into our next major release milestone, as I think you're correct that these are easy and high-impact areas for caching.
The intent is for this to be throttled to every five minutes. See https://buddypress.trac.wordpress.org/browser/tags/1.9.1/bp-core/bp-core-functions.php#L914. If this is failing, it's a bug.
A number of BP's options are stored in sitemeta when on Multisite, which is not auto-cached by WP. So we pre-load them.
We filter WP's 'illegal_names' option to prevent this kind of hijacking: https://buddypress.trac.wordpress.org/browser/tags/1.9.1/bp-members/bp-members-functions.php#L1023
Again, thanks for the helpful ticket. It's my personal priority for the 2.0 dev cycle to take care many of these wp_cache()-able items.