[buddypress-trac] [BuddyPress Trac] #5629: Slow queries with BP_Activity_Activity::get()

[buddypress-trac]

#5629: Slow queries with BP_Activity_Activity::get()
-------------------------+------------------
 Reporter:  Clean-Cole   |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  lowest       |   Milestone:  2.1
Component:  Activity     |     Version:  2.0
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |
-------------------------+------------------

Comment (by boonebgorges):

 Clean-Cole - This seems to me to be a good candidate for the transient
 cache, because it's such a specific bottleneck. Either way, the tricky
 part here is not caching the value so much as it is caching it in such a
 way that it's possible to invalidate it correctly. Ideally, a new activity
 item will only invalidate the cached count values that are relevant. For
 example, a new activity item "Boone joined group Foo" should invalidate
 (1) the sitewide activity count, (2) Boone's personal activity counts, (3)
 the My Groups activity counts for all members of Foo, (4) all counts for
 Foo that contain joined_group activity items (and possibly more), but you
 should not have to invalidate *all* cached counts.

 This gets very complicated very quickly. So, at a first pass, you might
 consider playing with one of the following ideas:
 a. Select a whitelist of counts that get cached. Eg, cache the count for
 the All filter on the sitewide stream, and maybe the All filters for each
 individual member, but no other filters. Then you'll have a relatively
 small list of things to invalidate.
 b. Flush all count-related caches whenever a new activity item is posted.
 This is technically the simplest solution, but has some obvious downsides.

 Thanks for looking ot this.

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