Skip to content

Reduce performance bar expiry to 5 minutes

Bob Van Landuyt requested to merge bvl-reduce-peek-expiry into master

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

  1. Check out this MR and restart puma.
  2. Enable the performance bar (press the p b sequence while on a GitLab page)
  3. 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.

Edited by Bob Van Landuyt

Merge request reports