아, 결국 해결했어요
첫 번째 수정은 문제의 일부만 다뤘습니다
흥미롭게도 이 문제는 “일반” 사용자에게만 영향을 미쳤고 "관리자"에게는 영향을 주지 않아서, 제가 직접 재현하지 못했던 겁니다
그룹을 검색할 때 결과는 알파벳 순서로 반환됩니다. 관리자는 모든 그룹을 볼 수 있으므로 "L"에 대한 첫 10개 결과는 'a’로 시작하는 작은 그룹들(예: “ai-personas” 및 기타 비공개 그룹)이었어요. 일반 사용자는 가시성이 더 제한적이므로, 결과에는 대규모 신뢰 수준 그룹이 포함되었습니다
일반 사용자가 보는 것:
trust_level_0: 62,506명
trust_level_1: 34,494명
trust_level_2: 4,727명
trust_level_3: 39명
trust_level_4: 13명
기타 더 작은 그룹들
총: 약 102,000명의 사용자 로드
관리자가 보는 것:
a*****: 4명
a*****: 76명
a*****: 0명
a*****: 2명
ai-personas: 138명
등등
총: 약 240명의 사용자 로드
main ← fix-chatables-timeout-regular-users
merged 09:20PM - 30 Dec 25 UTC
The previous fix (a5199830d1) updated the serializer to use SQL COUNT instead of… loading all users in Ruby, but forgot to remove the `.includes(users: :user_option)` from the service. This meant we were still loading ALL users of every matching group... for nothing! 😅
This caused 502 timeouts for regular users but not admins 🤔
Why? When searching groups, results are returned alphabetically. Admins can see all groups, so their first 10 results for "L" were small groups starting with 'a'. Regular users have limited visibility, so their results included the massive trust_level groups:
- trust_level_0: 62,506 users
- trust_level_1: 34,494 users
- trust_level_2: 4,727 users
That's 100k+ users being loaded into memory for no reason! 💥
The fix removes the unnecessary `.includes()` and adds a spec to prevent regression, plus a comment explaining why we shouldn't eager load users here.
Ref - https://meta.discourse.org/t/392286
1개의 좋아요
채팅 필터에서 그룹을 검색할 때 비효율적인 데이터베이스 쿼리가 추가로 실행되고 있었거든요. 검색어와 일치하는 그룹에 따라 쿼리 완료에 매우 오랜 시간이 걸릴 수 있었는데, 때로는 요청 타임아웃을 초과하기도 했어요.
이것이 느린 쿼리의 원인이었죠.
