Cache: actions/cache is much slower on Windows

Created on 30 May 2020  路  11Comments  路  Source: actions/cache

Hi,

I'm not sure if this is a known issue, or I'm doing something wrong, but this action runs much much slower on windows runners for me. I tried finding issues related to this, but couldn't find any.

This is not terribly important, but it does force me to wait about four minutes longer for mi CI to run.

You can see this in action here:

Note that there are non-windows jobs, where actions/cache run much faster.

btw, thanks for releasing v2. It's a HUGE improvement.

Most helpful comment

@flybayer We ended up using the Azure Storage SDK for NodeJS instead of Azcopy. This was primarily done so we have better control over versioning and will also work out-of-the-box for self-hosted runners. This change is merged in toolkit/cache (see https://github.com/actions/toolkit/pull/497 and https://github.com/actions/toolkit/pull/497) and has been published to NPM. The last step is updating the version used by the cache action (see https://github.com/actions/cache/pull/375) and updating the release tag.

All 11 comments

Yup, confirmed. It's super slow on Windows to the extent it beats the point of having cache :/

Windows is still using gzip which is slower than the zstd compression that's used in Linux and macOS runner.

Thanks for the answer, @aiqiaoy! Will this change in the future?

Windows cache is too slow to the point that installing my 700mb dependencies from scratch takes about 100 seconds while caching and then installing takes about 90 seconds, then there is the time to cache when my dependencies change... Because of this now I don't use caching at all. Hope you change the compression algorithm and make it faster.

@galtonova Yes, the compression algorithm is definitely something we will need to fix. I'm also working on another improvement to help reduce the download time - https://github.com/actions/toolkit/pull/493. However, this requires a new tool to be installed on the Windows runners. Progress installing that tool can be tracked here - https://github.com/actions/virtual-environments/pull/1008.

Any update on this now that https://github.com/actions/virtual-environments/pull/1008 is merged?

@flybayer We ended up using the Azure Storage SDK for NodeJS instead of Azcopy. This was primarily done so we have better control over versioning and will also work out-of-the-box for self-hosted runners. This change is merged in toolkit/cache (see https://github.com/actions/toolkit/pull/497 and https://github.com/actions/toolkit/pull/497) and has been published to NPM. The last step is updating the version used by the cache action (see https://github.com/actions/cache/pull/375) and updating the release tag.

Since #375 is now merged, is there anything we need to do to consume this improved cache action if we're using actions/cache@v2?
Will there be a new release of actions/cache that includes this improvement?

actions/[email protected] is published. Sorry for the delay getting this out, I found a bug in the version after posting above and had to push out a fix.

You can see performance comparison on a 2.5 GB cache file - https://github.com/dhadka/cache-canary/runs/895195362?check_suite_focus=true

Windows is still slightly slower than Ubuntu and Mac at 97 seconds, but this should be a substantial improvement compared to the 4 minutes needed to download the 818 MB cache that started this issue.

And the @v2 tag is updated to the same commit as @v2.1.0

Closing issue. If you continue to see slowness, please post in https://github.com/actions/cache/issues/267 which is a catch-all for network slowness.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

binkley picture binkley  路  4Comments

dhadka picture dhadka  路  5Comments

KhaledSakr picture KhaledSakr  路  3Comments

hugovk picture hugovk  路  6Comments

jwt27 picture jwt27  路  3Comments