[buddypress-trac] [BuddyPress Trac] #7436: Very slow check_is_friend function

buddypress-trac noreply at wordpress.org
Mon Feb 6 20:55:42 UTC 2017

#7436: Very slow check_is_friend function
 Reporter:  januzi_pl     |       Owner:
     Type:  defect (bug)  |      Status:  new
 Priority:  low           |   Milestone:  2.7.5
Component:  Friends       |     Version:  2.7
 Severity:  major         |  Resolution:
 Keywords:  dev-feedback  |

Comment (by dcavins):

 Replying to [comment:6 r-a-y]:
 > Is there a need to fetch all of the user's friendship IDs in one fell
 swoop in `BP_Friends_Friendship::get_friendships()` when we are just doing
 a one-to-one check as is the case in

 The idea was to reduce database lookups on member directories, for
 instance, where you're going to check against 20 other members. We could
 do 20 one-to-one checks, but the caching strategy was designed to get the
 friends list one time then compare against it 20 times. I'll admit that I
 didn't imagine a use-case where a user would have 20,000 friends. :) In
 this user's case, he'd be better off doing 20 narrowly targeted database
 lookups. (I'm not sure at what volume the performance tradeoff happens,

 We use a similar approach for group membership, which works great for most
 use cases, but if a member belongs to 20,000 groups, we'd have the same
 problem. I imagine this is true for most of our ID-based caching/filtering
 approaches: huge numbers of relationships are going to cause problems in
 some setups. I think @boonebgorges is having some thoughts about disk- vs
 memory-based caching performance.

 Maybe we could add some sort of escape hatch when the results list is
 massive. Or a filter so that site users could choose which behavior works
 better for them.

Ticket URL: <https://buddypress.trac.wordpress.org/ticket/7436#comment:7>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac

More information about the buddypress-trac mailing list