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

performance: what can dist-spec do to improve downloads of large images/layers? #536

Open
rchincha opened this issue May 28, 2024 · 7 comments

Comments

@rchincha
Copy link
Contributor

Things we already allow/do:

  1. Parallel download of layers

Things we can likely improve:

  1. For large layers, range-based downloads - download sections of a large file using Range Header and stitch them back together?

Things known to the community:

  1. https://github.com/containerd/stargz-snapshotter/blob/main/docs/estargz.md
    ^ fuse based filesystem solutions - copy individual things when referenced
@sudo-bmitch
Copy link
Contributor

What changes are needed in distribution-spec to support this? Is a pointer to the HTTP specs documenting range requests enough?

@rchincha
Copy link
Contributor Author

@rchincha
Copy link
Contributor Author

rchincha commented May 28, 2024

What changes are needed in distribution-spec to support this? Is a pointer to the HTTP specs documenting range requests enough?

IMO, what server/client side optimizations can be enabled by dist-spec changes? demonstrably?

Just like conformance, we should write benchmark code for this.

@sudo-bmitch
Copy link
Contributor

Just like conformance, we should write benchmark code for this.

Is that an OCI requirement, or something implementations should be doing?

@rchincha
Copy link
Contributor Author

rchincha commented Jun 9, 2024

Just like conformance, we should write benchmark code for this.

Is that an OCI requirement, or something implementations should be doing?

Not an OCI requirement - our conformance suite should already ensure conformant registries can handle range-based blob pulls.

#537 (comment)
^ will be interesting to see data from various registries. If viable, clients should move to this model advised by blob size.

@rchincha
Copy link
Contributor Author

#546

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

3 participants