Caching for the activity component

[boonebgorges]

We currently do (almost) no caching in the activity component. We should.

There are two kinds of entities that would benefit from caching throughout bp-activity: *items* and *queries*.

Activity items will be fairly straightforward to cache. I suggest the following lines of attack:

• In BP_Activity_Activity::get(), after we've pulled up data associated with individual activity items matching the query, put it in item-specific cache slots.
• Assuming we split our activity query as suggested in #5349, we can then use the activity item cache when we fill in the missing data about each activity item. See ​https://core.trac.wordpress.org/browser/tags/3.8/src/wp-includes/query.php#L2927 for a similar tactic in WP_Query.
• Cache busting as appropriate.

*Query* caching will be a good deal more complex, and will probably be best saved for after item caching is in place. The problem is invalidation. A single activity item (say, "Boone posted an update in the group Foo") is associated with multiple BP (Boone, Foo) and multiple activity query types (sitewide stream, Boone's stream, Foo's stream, My Groups for anyone who is a member of Foo, My Friends for any of Boone's friends, etc). I've been working for a while on a more formal proposal for working around this problem, but the short version is: we store (in cache) an index of cache keys, where a given query cache key will be listed with multiple associated items (eg, the cache key associated with the "Boone's 20 most recent My Groups activity" query will be indexed with Boone as well as each of Boone's groups; then, when *any* of those items gets new activity, all associated cache keys are flushed. I'll work on something a little clearer than that, but consider this an initial idea-float.

[johnjamesjacoby]

cc

[boonebgorges]

5350.patch adds caching for individual activity data. Details:

• I'm only accessing the cache in BP_Activity_Activity::get() and in BP_Activity_Activity::populate(). This covers probably 95% of all activity queries in BuddyPress. (The activity component is probably the best of our components at channeling queries through a single point like this. Others will be more challenging.)
• As described above: after the activity IDs are fetched, I check the cache for each one. If found, the cached data is used. If there are items for which cached data is *not* found, we run a query only for those items' data, and fill in the $activities array with it.
• Activity item caches are busted on activity save and delete.

All my test with APC are showing that this is working properly (cache is being used when it should be, not used when it shouldn't be, and invalidated at the right times). Could use a second pair of eyes, though.

[boonebgorges]

I've done another round of testing, and am going to add this so that I can do some further implementation of the same technique.

As for the issue of query caching, I'm going to set that aside for the time being. Because of the radical improvements introduced by #5349, I think that the issue has become much less pressing. Also, there are many places throughout BP where we'll get more bang for our caching buck.

[boonebgorges]

In 7771:

Use persistent cache for individual activity items

Fixes #5350