Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Workshop show pages allocate ~7.3k objects per request with no caching (28% of app allocations)

Abierto
  • ¿Algo no está bien?
#2,951 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
52/100
Tipo de issue
Refactorización
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
rails, ruby
Área
backend, performance

Línea de trabajo

Start by re-measuring current allocations for WorkshopsController#show in the Codebar requests dashboard or canonical logs. Read the show action, the EventCardComponent and chapters_sidebar caching patterns, and EventsController lines 12/19; inspect the sponsors, venue, organisers_grid, newsletter, and actions sections. Done means materially lower allocations, unchanged logged-in behaviour, and 304 responses for unchanged anonymous views.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

performance

Issue 2951: Workshop show pages allocate ~7.3k objects per request with no caching (28% of app allocations)

Summary

WorkshopsController#show is the app's top allocation consumer: 28% of all allocations over the last 7 days (2026-09-21..27), from 24,701 successful renders — 43% of all traffic. Every workshop page view rebuilds everything from scratch: the page has no caching at all, while sibling pages already use it (EventCardComponent fragment cache, chapters_sidebar fragment, fresh_when in EventsController).

Measured

7-day window 2026-09-21..27 (canonical logs, payload.allocations): 204.8M allocations across 24,701 x 200s (plus 179 404s). Per-request cost is extremely uniform: p50 7,348, p90 8,985, p95 12,913, median 8 queries, view p50 10ms — so this is per-render rendering cost, not a query or outlier problem. These numbers are stale by the time you read this — re-measure from current logs or the Codebar requests dashboard (allocations panel) before starting.

Per-render allocators, in rough order:

  • sanitize(@workshop.description) — the Rails HTML sanitizer is one of the heaviest single calls per render
  • shared/sponsors, shared/venue, members/organisers_grid, shared/newsletter partials and the layout re-render every request
  • no fragment caching anywhere on the page

Suggested directions

  1. HTTP caching for anonymous GETs — fresh_when with an etag on [@workshop.cache_key_with_version, ...], gated on !logged_in? (the actions partial is per-user). The pattern already exists at EventsController lines 12/19. Crawlers and repeat anonymous visits then get 304s with near-zero allocations.
  2. Fragment-cache the static sections (sponsors, venue, organisers grid) keyed on the workshop cache key — this also cuts allocations for logged-in views.
  3. Sanitize once on write (or cache the sanitized HTML) rather than per render.

Verify

payload.allocations p50 for WorkshopsController#show drops materially on the allocations panel; no visual or behavioural regression for logged-in members; conditional GETs return 304 for unchanged anonymous views.

Related: #2886-#2888 (same measurement method), #2891 (404 tail already resolved by the route constraint)

Lenguaje dominante
Ruby
Estrellas
104
Forks
205
Merge medio
1 d 2 h
PR fusionados (30 d)
77

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de codebar/planner

Todos los issues de codebar/planner

Issues similares

Más issues de Ruby

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.