[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
 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