You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When performing something like a cargo update operation, gitlab-cargo-shim will
Fetch all packages via /projects/{}/packages (calling multiple times if there are multiple pages)
Fetch each package release checksum via /projects/{}/packages/{}/package_files
Fetch each release's metadata via /projects/{}/packages/generic/{}/{}/{}
This activity is the source of most of the latency currently as these can take a while. Particularly the first activity after startup:
INFO ssh: gitlab_cargo_shim: Successfully authenticated for GitLab user `alexheretic` by Build or Personal Token
INFO ssh:data:build_packfile: gitlab_cargo_shim: Fetched crate releases in 8.8s
INFO ssh:data:build_packfile: gitlab_cargo_shim: Fetched crate metadata in 23.1s
However, metadata fetches (3.) are cached and so fast on subsequent operations:
INFO ssh: gitlab_cargo_shim: Successfully authenticated for GitLab user `alexheretic` by Build or Personal Token
INFO ssh:data:build_packfile: gitlab_cargo_shim: Fetched crate releases in 6.3s
INFO ssh:data:build_packfile: gitlab_cargo_shim: Fetched crate metadata in 3.2ms
This makes me wonder if we can also improve 1. & 2. with caching. I think for 1. the answer is "no". The server needs to provide new releases that may have been added since the last call.
But for 2. there is perhaps more that can be done. This checksum won't generally change for a given release. It can happen if the release has been re-published overwriting the previous file, which is possible. However, in my case publishing is as immutable as possible, simulating crates-io. The most likely time I might re-publish would be close to the original publish time to fix some error.
That suggests we could cache checksum fetches for releases older than some configurable period of time as older releases are much less likely to be modified. E.g. config:
# configuration## Cache file checksum fetches for all release older than this value## If omitted no caching will occur.cache-releases-older-than = "7 days"
The text was updated successfully, but these errors were encountered:
This sounds reasonable to me, I have some unreleased changes that need clearing up to move the cache to rocksdb too to avoid boot latency.
I've also been experimenting with the GraphQL API for some unrelated things wrt. group-level registries, might be able to use GraphQL here too for some cool things with after to avoid recursing the entirety of packages for packages that have already been seen
I have some unreleased changes that need clearing up to move the cache to rocksdb too to avoid boot latency.
I've also been thinking about a way to startup with a pre-filled metadata (and now checksum) cache. That would be very helpful for my use case to reduce first request latency.
When performing something like a
cargo update
operation, gitlab-cargo-shim will/projects/{}/packages
(calling multiple times if there are multiple pages)checksum
via/projects/{}/packages/{}/package_files
/projects/{}/packages/generic/{}/{}/{}
This activity is the source of most of the latency currently as these can take a while. Particularly the first activity after startup:
Note: Using the latency logs introduced in #74.
However, metadata fetches (3.) are cached and so fast on subsequent operations:
This makes me wonder if we can also improve 1. & 2. with caching. I think for 1. the answer is "no". The server needs to provide new releases that may have been added since the last call.
But for 2. there is perhaps more that can be done. This checksum won't generally change for a given release. It can happen if the release has been re-published overwriting the previous file, which is possible. However, in my case publishing is as immutable as possible, simulating crates-io. The most likely time I might re-publish would be close to the original publish time to fix some error.
That suggests we could cache checksum fetches for releases older than some configurable period of time as older releases are much less likely to be modified. E.g. config:
The text was updated successfully, but these errors were encountered: