Meeting show pages run 63-93 queries per request (attendee N+1)
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 2/5
- Thời gian dự kiến
- 1-3 giờ
- Mức phù hợp với người mới
- 74/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Lĩnh vực
- backend, performance
Hướng nghiên cứu
Bắt đầu với MeetingsController#show và app/views/meetings/show.html.haml để theo dõi cách những người tham dự và các thành viên của họ được tải và render. Đo lại số lượng query hiện tại từ Codebar requests dashboard trước khi thực hiện thay đổi. Được coi là hoàn tất khi trang show được render giống hệt và p50 của queries_count giảm từ mức ~63 được báo cáo xuống còn một chữ số.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Summary
MeetingsController#show runs 63 queries per request (median), 93 at p95 for a page with ~60 attendees — a classic N+1. Only 412 requests in the last 7 days so this is small in aggregate (1.6% of allocations), but the per-request cost is the worst query-count in the app and cheap to fix.
Measured
7-day window 2026-09-21..27 (canonical logs): 412 requests, allocations p50 25,679, queries_count p50 63, p95 93. Re-measure from current logs before starting.
The loop in app/views/meetings/show.html.haml touches attendee.member.avatar(56) and attendee.member.full_name per row, and @attendees is built without preloading:
@attendees = @meeting.invitations.where(attending: true)
each attendee then triggers a members lookup (plus whatever avatar loading costs).
Suggested directions
- Preload members:
@meeting.invitations.where(attending: true).includes(:member) - Check
members/organisers_gridfor the same pattern on@meeting.organisers - While there:
sanitize(@meeting.description)runs per render — cache the fragment or sanitize on write (same treatment as #2951)
Verify
queries_count p50 for MeetingsController#show drops from ~63 to single digits on the Codebar requests dashboard; page renders identically.
Related: #2951, #2952 (same measurement method)
- Ngôn ngữ chính
- Ruby
- Star
- 104
- Fork
- 205
- Merge trung bình
- 1 ngày 2 giờ
- Pull request đã merge (30 ngày)
- 77
Chuẩn bị môi trường
- Có Dockerfile hoặc tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của codebar/planner
-
enhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 56/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Chapter show pages allocate ~21k+ objects per render for large chapters (18% of app allocations)Đang mởperformance
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 55/100
codebar/planner#2952 · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Workshop show pages allocate ~7.3k objects per request with no caching (28% of app allocations)Đang mởperformance
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 52/100
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của codebar/planner
Issue tương tự
-
enhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 2 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
jetrockets/jet_ui#47 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
FreeCAD/homebrew-freecad#870 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
-
Messages with a markdown image that has a relative or malformed URL throw TypeError: Invalid URLĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày