codebar / codebar/planner

/events/upcoming: 31 queries and ~467ms median per render

Open
#2,888 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

performance
Dominant language
Ruby
Stars
104
Forks
205
Avg merge
1d 5h
Merged PRs (30d)
63

Description

Summary

GET /events/upcoming (EventsController#upcoming) takes a median 467ms per render (max 13.7s) and issues 31 queries (median db_runtime 83ms). The action sets an ETag via fresh_when, so conditional requests are cheap, but non-conditional clients (first visit, stale cache, most API clients) pay the full render every time.

The render path:

  1. paginated_events runs a UNION ALL across Workshops, Meetings, and Events, counts at the DB level, and returns only the 20 rows for the current page
  2. load_events runs three eager_load queries (workshops, meetings, events) for those rows
  3. fetch_upcoming_events groups the rows by date and wraps each in a presenter (EventPresenter.decorate_collection)
  4. The view renders EventCardComponent.with_collection — each card is fragment-cached (event_card_component/* keys in Solid Cache)

31 queries is well over the handful that steps 1–2 need, so something in decoration or rendering loads associations the current eager loads don't cover.

Measured

3h window on 2026-09-16/17, from production canonical logs: 122 requests, median 467ms, max 13.7s. Stale by the time you read this — re-measure before starting.

Suggested directions

  1. Capture the 31 queries locally (Bullet or Prosopite against a production dump) and identify the associations touched during decoration and card rendering beyond the current eager_load calls
  2. Add the missing associations to the eager loads or batch them into a single preload, preserving the UNION order
  3. Check the hit rate on the per-event fragments before adding more caching — they may already absorb most of the view time

Verify

Query count and median duration drop; ETag behaviour unchanged.

Related

  • #2887 — the sibling /events/past action, same code path; share findings
  • #2885 — same measurement window

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at EventsController#upcoming and re-measure the current query count and render time, since the reported production measurements are stale. Trace paginated_events, load_events, fetch_upcoming_events, EventPresenter.decorate_collection, and EventCardComponent with Bullet or Prosopite to identify missing association loads. Done means lower query count and median duration while preserving UNION order and ETag behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
rails, ruby
Domain
backend, database, performance
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
52/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.