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

[buddypress-trac]

#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
 `BP_Friends_Friendship::check_is_friend()`?

 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,
 truthfully.)

 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