Skip to:

Opened 4 years ago

Closed 4 years ago

Last modified 21 months ago

#5350 closed enhancement (fixed)

Caching for the activity component

Reported by: Boone Gorges Owned by: Boone Gorges
Milestone: 2.0 Priority: normal
Severity: normal Version:
Component: Activity Keywords: has-patch needs-testing


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 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.

Attachments (1)

5350.patch (3.5 KB) - added by Boone Gorges 4 years ago.

Download all attachments as: .zip

Change History (7)

This ticket was mentioned in IRC in #buddypress-dev by boonebgorges. View the logs.

4 years ago

#3 @Boone Gorges
4 years ago

  • Keywords has-patch needs-testing added
  • Milestone changed from Future Release to 2.0

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.

@Boone Gorges
4 years ago

#4 @Boone Gorges
4 years ago

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.

#5 @Boone Gorges
4 years ago

  • Owner set to Boone Gorges
  • Resolution set to fixed
  • Status changed from new to closed

In 7771:

Use persistent cache for individual activity items

Fixes #5350

#6 @Paul Gibbs
21 months ago

  • Type changed from task to enhancement
Note: See TracTickets for help on using tickets.