Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đã đóng
  • Có gì không ổn?
#2,951 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

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ó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
52/100
Loại issue
Tái cấu trúc
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
rails, ruby
Lĩnh vực
backend, performance

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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)

Ngôn ngữ chính
Ruby
Star
104
Fork
205
Merge trung bình
1 ngày 4 giờ
Pull request đã merge (30 ngày)
77

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của codebar/planner

Tất cả issue của codebar/planner

Issue tương tự

Thêm issue về Ruby

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.