Slow action cache checks - please revert 1e17348da7e45c00cb474390a3b8ed3103b6b5cf
- Dominant language
- Java
- Stars
- 25.8k
- Forks
- 4.6k
- Avg merge
- 2d 20h
- Merged PRs (30d)
- 72
Description
### Description of the bug:
@meisterT enabled the action cache throttle in 1e17348da7e45c00cb474390a3b8ed3103b6b5cf, but the description doesn't have any benchmark results or any other data supporting the claim that nobody would want this to be disabled. I had to go back to a fairly old commit in our own repo, but it looks like it has a significant impact on build times for us:
with the throttle enabled: 1m 31s
with the throttle disabled: 1m 19s
I wasn't able to get a cleaner signal, but we can clearly see the "acquiring semaphore" pieces in the profile:
throttle enabled:

throttle disabled

We can see that the action cache checks with throttling take until ~60s, while the action cache checks without throttling take until ~40s.
### Which category does this issue belong to?
Performance
### What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
_No response_
### Which operating system are you running Bazel on?
Linux
### What is the output of `bazel info release`?
7.0.0-pre.20230530.3
### If `bazel info release` returns `development version` or `(@non-git)`, tell us how you built Bazel.
_No response_
### What's the output of `git remote get-url origin; git rev-parse master; git rev-parse HEAD` ?
_No response_
### Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.
It looks like commit https://github.com/bazelbuild/bazel/commit/1e17348da7e45c00cb474390a3b8ed3103b6b5cf removed the flag which can be used to work around the issue.
### Have you found anything relevant by searching the web?
_No response_
### Any other information, logs, or outputs that you want to share?
_No response_
Contributor guide
Assessment
This issue has not been assessed yet.