🐛 - Seeing 10s minimum time for all cache restores

[alexellis]

Describe the bug

Hi, @welteki has been trying out this action for self-hosted runners. It seems like every time a restore is done, even for 1MB from a local network using Minio or Seaweedfs, there's a 10s minimum penalty.

For the same amount of data, GitHub's hosted cache can be as little as a second or lower.

To Reproduce

Simply use the action, configured with S3 over the same LAN where the self-hosted runner is running.

Expected behavior

Faster, or as fast as GitHub's hosted cache.

Screenshots

Local cache with testpkg/actions-cache:

Bundler cache - 273.39MB, 11s Yarn cache - 454.25MB, 11s Plugins gems cache - 53.85MB, 10s App state cache - 1.4MB, 10s

GitHub cache on self-hosted runner:

Bundler cache - 261MB, 13s (high 20s) Yarn cache - 433MB, 18s (high 24s) Plugins gems cache - 51MB, 3s App state cache - 1MB, 2s

GitHub's cache on hosted runner:

Bundler cache - 261MB, 6s Yarn cache - 434MB, 11s Plugins gems cache - 51MB, 3s App state cache - 1MB, 2s

Code/Script reproduction

Perhaps @welteki can paste in a minimal example here?

Additional context

Feel free to ask for additional context if there's anything that would help?

[jackieli-tes]

can you enable verbose logging and share the actions log?

In our setup, the restoring is under 3 seconds even for caches > 1GB

[welteki]

Hi @jackieli-tes

I identified the cause of the issue we were seeing here and opened a PR with a fix. https://github.com/tespkg/actions-cache/pull/44

[jackieli-tes]

@welteki Thanks for the issue and the PR!