Improve efficiency of Discussion caching for merge requests
Currently, we store the serialized discussions in Redis from IssuableActions#discussions
. From the investigation in gitlab-com/gl-infra/scalability#1601 (comment 1015069256) this cache key occupied just more than 5GB of memory at the time we sampled.
The investigation also shows that the keys live quite long without being used (avg idletime of 6 hours), that's lower than the 1 day expiry set on them because we have likely evicted the key before the TTL was expired.
This cache can't be shared across users, because not all users can see the same information in the rendered notes.
The cache namespace cache:gitlab:DiscussionSerializer:
accounted for about 15% of the memory usage of the total cache:
namespace
Proposal
Since the cache isn't useful for any other user, and only used by our frontend, would it make sense to switch to client-side (ETag) caching for this instead? This is similar to what we do for the issue discussions in the same controller.