Skip to content
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

Open
dtolnay opened this issue Jan 5, 2024 · 3 comments
Open

Consider providing zstd tarballs on static.r-l.o #97

dtolnay opened this issue Jan 5, 2024 · 3 comments

Comments

@dtolnay
Copy link
Member

dtolnay commented Jan 5, 2024

To compensate for #89.

Decompression is probably still faster with .gz but if we care about that zstd-compression is probably the better option.

I benchmarked rustc + rust-std + cargo + clippy + rustfmt + llvm-tools to help choose a compression level:

compression size (MB) extraction time (sec)
none 649 N/A
gz 215 3.6
xz 127 8.4
zstd -1 232 1.2
zstd -2 217
zstd -3 207 1.2
zstd -4 203
zstd -5 198
zstd -6 193
zstd -7 190
zstd -8 188
zstd -9 184
zstd -10 182 1.25
zstd -11 182
zstd -12 181
zstd -13 181
zstd -14 181
zstd -15 180
zstd -16 174
zstd -17 166
zstd -18 159
zstd -19 158 1.4
@dtolnay
Copy link
Member Author

dtolnay commented Jan 5, 2024

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.

UebelAndre pushed a commit to bazelbuild/rules_rust that referenced this issue Jan 5, 2024
…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.
@dtolnay
Copy link
Member Author

dtolnay commented Feb 18, 2024

@criemen
Copy link

criemen commented Jul 19, 2024

Is there any update on this? I'm using rules_rust in CI (github actions), so I'm downloading rust a lot, and we're really suffering those decompression times. It'd be great if we could get official zst tarballs, at least for releases!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants