Skip to:

Opened 10 years ago

Closed 10 years ago

Last modified 8 years ago

#5350 closed enhancement (fixed)

Caching for the activity component

Reported by: boonebgorges's profile boonebgorges Owned by: boonebgorges's profile boonebgorges
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 boonebgorges 10 years ago.

Download all attachments as: .zip

Change History (7)

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

10 years ago

#3 @boonebgorges
10 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.

10 years ago

#4 @boonebgorges
10 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 @boonebgorges
10 years ago

  • Owner set to boonebgorges
  • Resolution set to fixed
  • Status changed from new to closed

In 7771:

Use persistent cache for individual activity items

Fixes #5350

#6 @DJPaul
8 years ago

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