[buddypress-trac] [BuddyPress Trac] #5629: Slow queries with BP_Activity_Activity::get()
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
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/>
More information about the buddypress-trac