]> git.ipfire.org Git - thirdparty/git.git/commit - builtin/gc.c
maintenance: add get_random_minute()
authorDerrick Stolee <derrickstolee@github.com>
Thu, 10 Aug 2023 20:39:40 +0000 (20:39 +0000)
committerJunio C Hamano <gitster@pobox.com>
Thu, 10 Aug 2023 21:04:16 +0000 (14:04 -0700)
commit89024a0ab018bb6e8ad2e4a6500b98b889088c54
tree446ff717dc358f798accddb8a9403cf1d640e71c
parenta82fb66fed250e16d3010c75404503bea3f0ab61
maintenance: add get_random_minute()

When we initially created background maintenance -- with its hourly,
daily, and weekly schedules -- we considered the effects of all clients
launching fetches to the server every hour on the hour. The worry of
DDoSing server hosts was noted, but left as something we would consider
for a future update.

As background maintenance has gained more adoption over the past three
years, our worries about DDoSing the big Git hosts has been unfounded.
Those systems, especially those serving public repositories, are already
resilient to thundering herds of much smaller scale.

However, sometimes organizations spin up specific custom server
infrastructure either in addition to or on top of their Git host. Some
of these technologies are built for a different range of scale, and can
hit concurrency limits sooner. Organizations with such custom
infrastructures are more likely to recommend tools like `scalar` which
furthers their adoption of background maintenance.

To help solve for this, create get_random_minute() as a method to help
Git select a random minute when creating schedules in the future. The
integrations with this method do not yet exist, but will follow in
future changes.

To avoid multiple sources of randomness in the Git codebase, create a
new helper function, git_rand(), that returns a random uint32_t. This is
similar to how rand() returns a random nonnegative value, except it is
based on csprng_bytes() which is cryptographic and will return values
larger than RAND_MAX.

One thing that is important for testability is that we notice when we
are under a test scenario and return a predictable result. The schedules
themselves are not checked for this value, but at least one launchctl
test checks that we do not unnecessarily reboot the schedule if it has
not changed from a previous version.

Signed-off-by: Derrick Stolee <derrickstolee@github.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/gc.c
wrapper.c
wrapper.h