Skip to content

perf: Improve performance of computing number of not-cloned repos - Part 2

Warren Gifford requested to merge core/fast-clone-2 into master

Created by: mrnugget

This is the follow-up to the reversal of #4801 and contains the possible optimizations of the original version that I described in this comment.

Two ideas here:

  1. Instead of sending a list of repos to gitserver and getting a map of repos map (high GC pressure with 10s of thousands of repos), repo-updater loads the names of repos from the DB (as before) and then diffs that with the list of cloned repos it gets from gitserver.
  2. Use godirwalk to speed up generating the list of cloned repos

Benchmark:

Requests      [total, rate]            268, 1.00
Duration      [total, attack, wait]    4m27.132907627s, 4m27.00428269s, 128.624937ms
Latencies     [mean, 50, 95, 99, max]  299.813288ms, 187.452779ms, 1.309757467s, 2.679100469s, 3.326904015s
Bytes In      [total, mean]            26800, 100.00
Bytes Out     [total, mean]            44756, 167.00
Success       [ratio]                  100.00%
Status Codes  [code:count]             200:268
Error Set:

Result: the max latency is down to 3.3s from 6.91s! And the 99th percentile is down to 2.67s from 6.10s!

It's not as fast as the buggy version, but still a lot faster than the original version.

Test plan: go test and deployed & tested on k8s.sgdev.org

(There's another twist one can put on this solution by sending the list of repo names to gitserver and then changing gitserver to compute the number of cloned/not cloned on the fly. But my first estimates tell me that while this would require less data structures on the repo-updater side, it just shifts the memory pressure to the transport layer and gitserver.)

Merge request reports

Loading