winget-cli: Extremely slow download of large files from GitHub Releases in winget (compared to downloading same file in browser)
Brief description of your issue
I find the download speed of a large 1.29GB package in winget is orders of magnitude slower than downloading the same package in the browser.
Steps to reproduce
Run winget install kiwix.wikimed.electron in Terminal. Download for me is around 500Kb per second. It would take around 45 minutes to completely download the file, if not longer. In any case I didn’t wait around, it was too painful.
When I click on the download link provided in winget, and open it in my browser, on the same machine I get a download speed of 6.5Mb per second.
I have experienced this on multiple occasions on two different machines running on the same network. Winget is unusable for downloading this >1GB package.
Expected behavior
I expect similar download speeds to browser.
Actual behavior
See above – painfully slow.
Environment
Windows Package Manager (Preview) v1.3.692-preview
Copyright (c) Microsoft Corporation. All rights reserved.
Windows: Windows.Desktop v10.0.22000.613
Package: Microsoft.DesktopAppInstaller v1.18.692.0
About this issue
- Original URL
- State: open
- Created 2 years ago
- Reactions: 2
- Comments: 33 (9 by maintainers)
Apparently the issue is DO getting timeouts from github’s CDNs, resulting in DO thinking the maximum throughput is very low. They are considering how future code can better handle this, but there isn’t a lot we can do to fix this in winget right now.
Hopefully the service issues will resolve and things will go back to normal. If not, we can consider putting in something like “if github, don’t use DO”. Or maybe “if DO takes over X seconds to download Y MB, give up and fall back to wininet”.
The immediate options are:
wininetas the downloader; it is slower than DO because it is a very basic implementation, but since it isn’t trying to be smart it isn’t as affected by externalities.Absolute bandwidthlimits to prevent the throughput detection issue. a. Open Settings (🪟 + i ) b. FindDelivery Optimization advanced optionsc. SelectAbsolute bandwidthd. CheckLimit how much bandwidth is used for downloading updates in the foregrounde. Set to whatever limit you want (100 Mbps?)Well I’ve just done another test with the same file, and through winget the file downloaded 32MB (of a 1.29GB file) in around 40 seconds. So, without stopping winget, I ctrl-clicked the link that winget provides to the original paciage, I accepted the download in my browser, and the same file downloads over 200MB in around 6 seconds, while winget is still going at a snail’s pace. My PC is fully up to date, no updates being downloaded.
Is it the PowerShell download process? Is it single-threaded? There’s something very odd going on. It’s clearly not my local computer or connection. It used to be much faster than this in winget.
I’ve just hit the same thing, and the
wininetdownloader seems as fast as ever, whileDO(akadefault) is 🐌 (and not Turbo)Going to follow up with the DO team to see if they can help interpret the logs that I’ve collected.
Still suffering from this issue today with v1.5.2201 trying to upgrade Rancher Desktop or Podman Desktop. Setting the downloader to
wininetfixed it.i’m ok with the speed. i am sure there are faster servers and i have a 1 gigabit speed connection at home (docsis 3.1) but at least i don’t have to use firefox everytime i want to install a new version. cmd winget install/upgrade libreoffice is enough
@Karl-WE, I’ll check when I get the new version and report back.
I’m from the UK, and I mostly get these very slow speeds. I’m the developer of the WikiMed and Wikivoyage apps, which are very large because of the compressed copies of Wikipedia data contained in them, so I test installation of them a lot. Until very recently installation was completely broken with winget for large appx UWP apps due to a signature verification problem (signature was valid, but winget couldn’t get if from GitHub and errored out). Now, you can see from the logs that the signature verification still can’t be got, but instead winget defaults to downloading the app directly and verifying the signature after download, which is much better behaviour.
However, the speed is the issue under discussion here. Comparing winget install and Microsoft Store install of the same app (but different packages, because the winget one is on GitHub and the MS Store one is on the MS Store), the MS Store is way way faster, 5 or 6 mins versus 37 mins with the test logged above.
This isn’t a criticism of winget. The problem is in the interaction between winget and GitHub servers. However, if I direct-download the exact same package from GitHub in my browser, the download is normal speed (5 or 6 mins, rarely exceeding 10 mins for 1.29GB). To me, this implies that winget could speed things up considerably by defaulting to a simple PowerShell
Invoke-WebRequestcommand! The problem seems to come from the attempt to use Delivery Optimization. I think DO is highly acceptable for @hueldoeu’s use-case, when wanting to do background updates of a number of apps, but if you want to download an app and use it straight away, it’s frustratingly slow and is going to put people off from using winget (which I think is a great service, by the way – I just want to improve the UX).I’m not aware of any issues. Is it possible Windows Updates or something else is running in the background affecting the throughput for Delivery Optimization?