-
Notifications
You must be signed in to change notification settings - Fork 23
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
Extremely slow fetch speed #25
Comments
Hi @psarossy. That doesn't sound normal or expected. Could you provide an example of one of the specific images (if public)? To help debug this, it would be really useful if you are able to share one slow image name/tag that you are running. Outdated may have to make a several requests to the registry to find the number of tags "out of date". I can think of a few reasons this might get slow, but I'd be happy to debug the network requests from one of your public images, in order to start narrowing it down. |
Sure, here's the log from a fresh run.
|
I've reproduced this, and it seems that we are pulling each tag separately to get the dates from the manifest of the tag. For non-semver tags, we do this to figure out the sort order. Maybe we can change the product a little so instead of showing the number of releases behind, we show that you are behind and the latest release. Once we find 3 or 5 releases between the 2, we can show the output as red, and say something like "5+ releases behind" instead of counting each |
+1 still seeing this |
In the demo video it seems that this tool supposed to be able to fetch the latest/behind data in seconds per image.
On my cluster, it takes minutes per image, and since I have like 50 different images, after like 3-4 of them it also just times out and says "Unable to get image data" and exist...
I'm using a mix of docker.io, quay.io, ghcr.io and gcr.io
Any hints on whether I'm doing something incorrectly or if this is normal?
The text was updated successfully, but these errors were encountered: