Introduce caching on Projects::MergeRequestsController#show.json for sidebar_extras
Problem to solve
During investigation in #330893 (closed), noticed that Projects::MergeRequestController#show.json
with serializer
param set to sidebar_extras
can take a while for a large MR (example: https://staging.gitlab.com/gpt/large_projects/gitlabhq1/-/merge_requests/8785).
Locally, loading that action can take around ~500ms to load. We load this on every tab on the MR page. Profiling the endpoint shows that it takes most of the time serializing the response.
Proposal
While working on a PoC on how we can cache this endpoint (!63644 (closed)), noticed that it can go down up to ~80ms when cached.
In the PoC, we cache the serialized response via Rails.cache
. It's utilizing the Api::Helpers::Caching
module with some modification to work with Rails controllers instead of Grape API (see #render_cached
). This will cache the sidebar response.
To implement this, we can:
- Utilize the
#render_cache
or equivalent that will be implemented in #332967 (closed). - Check if we need to define
cache_context
so appropriate cache will be written/read depending on scenario (e.g. different cache should show up per user, uncached content should show up when sidebar data updates). By default, it uses theMergeRequest#cache_key
and that may be enough. - Define a cache expiration. 1 day seems fine.
- Implement it behind a feature flag then roll it out in a separate roll out issue. This way we can enable it on production and monitor how it affects our Redis cache usage.
Be on the look out for possible bug due to cache response is still being returned while it shouldn't.