Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Chiusa
  • Qualcosa non va?
#2,951 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
52/100
Tipo di issue
Refactoring
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
rails, ruby
Ambito
backend, performance

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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)

Lingua principale
Ruby
Stelle
105
Fork
206
Merge medio
1g 3h
PR unite (30g)
74

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di codebar/planner

Tutte le issue di codebar/planner

Issue simili

Altre issue su Ruby

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.