Reduce performance bar expiry to 5 minutes
What does this MR do and why?
Otherwise we'd use the default of 30 minutes. We generally don't need the data for this long, but we do want to have some buffer to be able to access historical data in the performance bar menu for a little while.
We populate this information on each request for a user that has access to the performance bar.
We also store a lot of information there including a detailed log of queries, Gitaly and Redis calls. This makes this object quite big.
This leads to us storing way more data for peek than we need to, contributing to us to hit maxmemory more often.
gitlab-com/gl-infra/scalability#1601 (closed)
Peek documentation: https://github.com/peek/peek#configuring-the-default-adapter
How to set up and validate locally
- Check out this MR and restart puma.
- Enable the performance bar (press the
p
b
sequence while on a GitLab page) - Check the performance bar keys that have been created in a Rails console using this snippet:
[37] pry(main)> Gitlab::Redis::Cache.with { |r| r.scan_each(match: 'peek:*') { |key| puts({ key: key, ttl: r.ttl(key)}) } }
{:key=>"peek:requests:01G6WVJHRFT6YAKNA8RS055G75", :ttl=>296}
The TTL's of new keys should be less than 300 seconds
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.