-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider providing zstd tarballs on static.r-l.o #97
Comments
At level 19, decompressing in 1.4 seconds is significantly faster than 8.4 seconds for xz. Users will notice this. The tradeoff is that this loses 35% of the bandwidth benefit of #89. The user must also be able to download 31 MB in 7 seconds (35 Mbps; 4.4 MiB/s) in order to see any benefit. For comparison, I get 90+ MiB/s from static.rust-lang.org so zstd would definitely be a speedup for me. Perhaps rustup could choose between xz and zstd based on the observed speed. I imagine rust-lang/rustup#731 would also be relevant to choosing optimally. |
…2399) Rust infra folks requested that I send this change. According to Rust's logs, currently 30% of bytes served by static.rust-lang.org are .gz tarballs, and primarily that is attributed to Bazel according to user-agent. The .gz tarballs are needlessly large and consume more bandwidth for Rust than we want to serve. This PR changes rules_rust to default to .xz tarballs instead. Rustup has been using xz downloads for the past 6.5 years. The default set of tars downloaded by rules_rust (rustc, rust-std, cargo, clippy, rustfmt, llvm-tools) is 215M in gz and 127M in xz, which is 41% smaller. If adopted, this PR would save static.rust-lang.org more than 12% of its bandwidth. As a tradeoff, decompressing that set of 6 files with xz is slower: 3.6 seconds for gz and 8.4 seconds for xz. (Single-threaded. If Bazel extracts different files in parallel than the magnitude of the difference would be smaller but the ratio is similar.) In rust-lang/infra-team#89 we intend to sunset gz downloads, or do something to push users away from them (such as throttling), so gz will be the wrong choice no matter what. To make up for decompression speed we are investigating providing zstd tarballs in rust-lang/infra-team#97 which decompress significantly faster than gz while being not much larger than xz.
Relevant discussion on the rustup side: |
Is there any update on this? I'm using |
To compensate for #89.
I benchmarked rustc + rust-std + cargo + clippy + rustfmt + llvm-tools to help choose a compression level:
The text was updated successfully, but these errors were encountered: