[buddypress-trac] [BuddyPress Trac] #5733: Use wp_cache_add_global_groups() so cache is applicable throughout multisite

[buddypress-trac]

#5733: Use wp_cache_add_global_groups() so cache is applicable throughout
multisite
--------------------------+-----------------------------
 Reporter:  wpdennis      |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Future Release
Component:  Core          |     Version:  2.0
 Severity:  minor         |  Resolution:
 Keywords:  2nd-opinion   |
--------------------------+-----------------------------

Comment (by johnjamesjacoby):

 We also have `wp_cache_add_non_persistent_groups()` at our disposal for
 things like counts. The function name is a little nondescript, but it
 caches results for the current page-load and skips the persistent cache.
 WordPress currently uses this for a few different groups:

 * 'comment'
 * 'counts'
 * 'plugins'
 * 'themes', with a `wp_cache_themes_persistently` filter to switch it to
 persistent

 This would allow us a bit of wiggle-room for adding caching without
 worrying too much about invalidation, at least not right away. One odd but
 good example of using this is WordPress comments. The 'comment' cache
 group is non-persistent, and all comments queries cache to that group.
 This means comment objects are not persistent, which was a pretty
 surprising realization. Helper functions like `clean_comment_cache()` and
 `update_comment_cache()` are used to update or invalidate multiple
 objects, and a `last_changed` hashed key is used to separate result sets,
 like: `$key = md5( serialize( wp_array_slice_assoc( $this->query_vars,
 array_keys( $defaults ) ) )  );`

 An approach like above makes more sense than our approach with
 `bp_activity_sitewide_front` for example. That custom front-page cache
 approach is a fine work-around for not having any caching, but does make
 the assumption that the front-page of the activity directory is the same
 for everyone. Once any parameters change, we stop caching queries, which
 leaves us room for improvement.

 Conversely for the `posts` group, it's non-global, and persistent, which
 seems more accurate for our components and their objects and queries.
 There are helper functions for building cache keys (similar to my proposal
 above) and objects are expected to be cached and deleted rather
 frequently, up to and including functions like `wp_insert_post()` that
 delete the new post`s cache and then immediately prime the cache with a
 call to `get_post()`.

 Still sifting through WordPress's innards, but we've always known there
 would be pretty enormous performance gains once we get our cache usages
 correct, and it's nice to reconfirm that.

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5733#comment:14>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac