commit 9bfeb0ea79e874bbadeb583492c0e5e91601f463
author Martin Fick <martin.fick@linaro.org> Wed Aug 09 10:04:58 2023 -0600
committer Martin Fick <martin.fick@linaro.org> Thu Sep 28 17:03:23 2023 -0600
tree 7aeb70ce2056a0bd62d2d7fea8bb80e3a57672fb
parent a7401b0131a8899295f91ad96b3de47e12cb4ad6

Add in memory change data cache by project

This cache only stores the data needed to speedup ref advertisements.
The index is used to populate this cache when it is available otherwise
it falls back to scanning noteDb (generally on replicas). This cache is
most useful when using 'git upload-pack' with projects with large change
counts on replicas.

The following times were seen when running 'git ls-remote' on a project
with around 380K changes stored on NFS:

With ES index (primary):
 Before this change: (cold 1m3s) 12-17s (with large enough "changes" cache)
 After this change:  (cold 1m3s) 12-17s (with large enough "changes" cache)
No Index (replica):
 Before this change: (cold ~4m)   ~4m
 After this change:  (cold 2m25s) 12-17s

Although the numbers above do not show an improvement on "best" times
for primaries using ES, that's because those numbers represent the times
achieved with the existing "changes" cache enabled. However, since the
existing "changes" cache is disabled by default, most sites will see an
improvement after this change with 'git upload-pack' on primaries also,
and additionally with 'git receive-pack'. Thus the warm times after this
change are more achievable and more likely to stay fast, even when other
projects are accessed in between. Before this change it is harder to
achieve and maintain the warm times.

The existing "changes" cache can also is used to help cache changes by
project, however, it is documented as not being appropriate for
multi-primary setups since it will be out of date if alterations are
made to changes outside of the current server. The existing cache is
also not useable on replicas where there is no index. It is noteworthy
that the existing cache provide value beyond just its ability to cache
results since loading change data from the index (even with ES), is
faster than loading change data via a noteDb scan.

Similar to the existing cache, the new cache is able to take advantage
of the index when it is available on primaries, however it is actually
multi-primary friendly because it stores the meta-ref id for each change
and out-of-date changes are detected on each cache fetch resulting in
the cache being incrementally kept up-to-date. The new cache is also
useable on replicas by also falling back to a noteDb scan when the index
is not available, however here too it is able to incrementally stay up
to date after the first scan.

The new cache is much more space efficient than the existing "changes"
cache as it takes advantage of the fact that determining visibility for
public changes requires access only to a change's destination branch and
that many changes are generally destined for each branch. So although
the existing cache is fairly compact, this new cache stores even fewer
change data fields. This makes it likely possible to keep all the
projects on a server cached in memory, even on servers with large
projects and change counts. It may make sense to eventually remove the
existing changes cache.

Release-Notes: Add cache to speedup ref advertisements (particularly on replicas) and receive-pack
Forward-Compatible: checked
Change-Id: Ib9c77ee03d9012cdeb6ad05eed3492c3009e4334