[buddypress-trac] [BuddyPress Trac] #7436: Very slow check_is_friend function
buddypress-trac
noreply at wordpress.org
Thu Nov 16 20:27:25 UTC 2017
#7436: Very slow check_is_friend function
--------------------------+------------------
Reporter: januzi_pl | Owner:
Type: defect (bug) | Status: new
Priority: high | Milestone: 3.0
Component: Friends | Version: 2.7
Severity: major | Resolution:
Keywords: dev-feedback |
--------------------------+------------------
Comment (by boonebgorges):
I've thought some more about this in the last few weeks.
We moved to a centralized system for caching this stuff in a desire to be
less redundant. But I wonder whether that's harmed the underlying purpose
of caching this kind of thing: namely, to improve performance. As such, I
wonder if we might leave the existing caching mechanism in place for
friend *lists* (and group member lists), but replacing the single friend-
check caching mechanism with a direct SQL query that lives in its own
cache. [attachment:7346.diff] is a very simple example of how this would
work. Invalidation (not in the patch) would be across *all* friendships
for the time being, and could maybe be more fine-grained in the future if
someone felt like figuring that out :)
This way, we retain the benefit of the caching for places where we
actually are querying lots of friends at once, but reduce overhead when we
don't need that info.
I do also think we should think about splitting up the way that the
friendship cache is primed, as I started to suggest in [comment:8 comment
8 above]. Here's a start: friendship object caching doesn't need to happen
for all of a user's friendships in the case where results are supposed to
be paginated https://buddypress.trac.wordpress.org/browser/tags/2.9.2/src
/bp-friends/classes/class-bp-friends-friendship.php?marks=267-275#L248.
Let's only prime these caches for the relevant 'per_page' number of items
- which also means that we should be diligent about using 'per_page=1' etc
when calling `get_friendships()` from elsewhere in BP. Actually, it may
pay to try this fix *first*, before attempting the restructure I described
above, since it might provide enough benefit to solve the problem
described in this ticket.
What do others think?
--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/7436#comment:16>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac
More information about the buddypress-trac
mailing list