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
We found in past benchmarks that ZYPP_MULTICURL=1 logic is always slower than ZYPP_MULTICURL=0 downloads, because TCP connections need a while to reach their maximum speed and because latency is a major factor when downloading in small chunks.
We should make ZYPP_MULTICURL=0 the default.
For that, we need to ensure, we have good automatic fallbacks, so that users don't get to see 404 errors, connection timeouts and such when we can avoid it.
Fallback could go to download.o.o, cdn.o.o or downloadcontentcdn.o.o - probably an URL provided by MirrorCache.
I need to do some more measurements.
I found ZYPP_MULTICURL=0 made things worse on the two systems I tested on. One was a VM in Singapur(Hetzner) and another was a Nuremberg machine on a slow powerline connection.
The measurements showed significant improvements from a hot CDN cache there. It changed the time from 110s to 10s. When using https://downloadcontentcdn.opensuse.org/tumbleweed/repo/oss/ the difference was 368s to 3.6s but I we do not want to use that mode widely as the large files make it too slow and costly.
We found in past benchmarks that
ZYPP_MULTICURL=1
logic is always slower thanZYPP_MULTICURL=0
downloads, because TCP connections need a while to reach their maximum speed and because latency is a major factor when downloading in small chunks.We should make
ZYPP_MULTICURL=0
the default.For that, we need to ensure, we have good automatic fallbacks, so that users don't get to see 404 errors, connection timeouts and such when we can avoid it.
Fallback could go to download.o.o, cdn.o.o or downloadcontentcdn.o.o - probably an URL provided by MirrorCache.
CC @dirkmueller @andrii-suse
The text was updated successfully, but these errors were encountered: