Meeting show pages run 63-93 queries per request (attendee N+1)
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 2/5
- Tiempo estimado
- 1-3 horas
- Aptitud para principiantes
- 74/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Área
- backend, performance
Línea de trabajo
Empieza por MeetingsController#show y app/views/meetings/show.html.haml para seguir cómo se cargan y renderizan los asistentes y sus miembros. Vuelve a medir el número actual de consultas desde el Codebar requests dashboard antes de hacer cambios. Se considera terminado cuando la página show se renderiza de forma idéntica y su p50 de queries_count baja de los ~63 indicados a un solo dígito.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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)
- Lenguaje dominante
- Ruby
- Estrellas
- 104
- Forks
- 205
- Merge medio
- 1 d 5 h
- PR fusionados (30 d)
- 72
Preparar el entorno
- Incluye un Dockerfile o un archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de codebar/planner
-
good first issue tech debt
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
Los mantenedores suelen responder en 1 día
-
good first issue refactoring tech debt
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
Los mantenedores suelen responder en 1 día
-
good first issue tech debt
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
Chapter show pages allocate ~21k+ objects per render for large chapters (18% of app allocations)Abiertoperformance
Dificultad 4/5 3-5 días Aptitud para principiantes 55/100
Los mantenedores suelen responder en 1 día
Todos los issues de codebar/planner
Issues similares
-
P2 testing
Dificultad 1/5 Menos de una hora Aptitud para principiantes 90/100
Los mantenedores suelen responder en 1 día
-
Blame view link labels are wrongAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
openSUSE/open-build-service#20338 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
DB上でコメント本文がNULLを許容しているAbiertoバグ
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100