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

buddypress-trac noreply at wordpress.org
Mon May 12 13:34:05 UTC 2014


#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):

 > So I figured any queries using since, action, or primary/secondary id
 should be excluded from a transient. So basically an all activity count
 for a user is the only thing we can really cache reliably?

 I guess I'd also consider group counts ('component' => 'groups', 'item_id'
 => $group_id ).

 > ? Another issue I considered was that if we save a user's total activity
 in a transient, the options table could easily get too bloated. Do you
 think storing a user's total activity count inside BuddyPress user meta is
 a viable alternative?

 I definitely would *not* use usermeta. At least in the case of transients,
 the WP API is smart enough only to grab the values that it needs when it
 needs them, and they're stored in memory when a persistent cache is
 available.

 That said, the more I think about this, the more I think that any kind of
 caching is bound to be problematic. What we're considering here is caching
 many, many very small values (integer counts). This causes problems on
 various caching schemas, due to data fragmentetation and internal
 invalidation logic. On a site with many users, we could be talking about
 hundreds of thousands of additional values to cache.

 Given these considerations, I think the correct thing to do is probably to
 use `wp_cache_` for these values. That way BP doesn't have to make guesses
 about how the specific caching backend is going to work, and optimization
 can be left up to site admins.

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


More information about the buddypress-trac mailing list