The workhorse_auth_api Apdex (This is the indicator that has had some huge drops lately, for example:  [git dashboard](https://dashboards.gitlab.net/d/git-main/git-overview?orgId=1&viewPanel=3139093701&from=1613061834274&to=1613084692267) Looking at the logs for the same timeframe, we can see that p99 database duration-peaks seem to correlate for the git-upload-pack endpoint:  https://log.gprd.gitlab.net/goto/3e4a237bbdbe6c76da4fcfffd5502203 @andrewn was sampling postgres to investigate database locks on the `project_daily_statistics`, using the info from marginalia to tie the queries to endpoints and noticed that there were a lot of queries for `git_upload_pack` marked as `idle`: [gdoc with raw data](https://docs.google.com/spreadsheets/d/1D6Z95xEfDuhmTpWfPKsWuFJQCz8ozxK2mPODttmwks4/edit?skip_itp2_check=true&pli=1#gid=723981321) Which makes us think we should improve the way we track these fetch statistics ### Proposals 1. Remove the tracker all together: we only increment this counter for git-https, but not over SSH. Which means the counter doesn't paint an entirely accurate picture. So perhaps this counter, that is only accessible through [this API endpoint](https://gitlab.com/gitlab-org/gitlab/blob/aadead890239da04eedc887f1e4a6fd0c6c76292/lib/api/project_statistics.rb#L4), could be removed? 1. Only periodically increment a counter in the database, while keeping a live counter in Redis. When incrementing the counter, we schedule a sidekiq job with a delay of a few minutes that can be deduplicated (using [`deduplicate :until_executing, including_scheduled: true`](https://docs.gitlab.com/ee/development/sidekiq_style_guide.html#scheduling-jobs-in-the-future).