Download is slow; diagnostic tools are unusable

[am11]

When I download a .NET SDK tarball from http://aka.ms/dotnet/net5/5.0.1xx/daily/Sdk/dotnet-sdk-linux-x64.tar.gz (133 MB), it is served via Verizon CDN, and hence results in a decent transmission rate:

$ wget http://aka.ms/dotnet/net5/5.0.1xx/daily/Sdk/dotnet-sdk-linux-x64.tar.gz
...
HTTP request sent, awaiting response... 200 OK
Length: 139267404 (133M) [application/octet-stream]
Saving to: ‘dotnet-sdk-linux-x64.tar.gz’

dotnet-sdk-linux-x64.tar.gz                       
100%[======================================================================================
=============================>] 132.82M  3.24MB/s    in 49s     

2020-12-16 06:54:48 (2.69 MB/s) - ‘dotnet-sdk-linux-x64.tar.gz’ saved [139267404/139267404]

However, downloading a smaller blob from symstore via dotnet symbol -d singlefilehost (113 MB) times out after 4 minutes.

$ dotnet symbol -d singlefilehost
Downloading from http://msdl.microsoft.com/download/symbols/
ERROR: The operation was canceled. -> Unable to read data from the transport connection: Operation canceled.

httpry(1) shows the URL to file:

$ sudo httpry -i enp0s8
...
2020-12-16 07:01:31	192.168.1.224	204.79.197.219	>	GET	msdl.microsoft.com	/download/symbols/_.debug%2Felf-buildid-sym-6ca69f7bc7061d8eab20013d6820ef5a5c2f7ff4%2F_.debug	HTTP/1.1	-
2020-12-16 07:01:32	204.79.197.219	192.168.1.224	<	-	-	-	HTTP/1.1	302	Found

tried that URL with wget(1):

$ wget http://msdl.microsoft.com/download/symbols/_.debug%2Felf-buildid-sym-6ca69f7bc7061d8eab20013d6820ef5a5c2f7ff4%2F_.debug
...
HTTP request sent, awaiting response... 200 OK
Length: 118073560 (113M) [application/octet-stream]
Saving to: ‘_.debug%2Felf-buildid-sym-6ca69f7bc7061d8eab20013d6820ef5a5c2f7ff4%2F_.debug’

_.debug%2Felf-buildid-sym-6ca69f7bc7061d8eab20013d6820ef5a5c2f7ff4%2F_.debug 
100%[======================================================================================
=============================>] 112.60M   204KB/s    in 14m 23s 

2020-12-16 07:17:02 (134 KB/s) - ‘_.debug%2Felf-buildid-sym-6ca69f7bc7061d8eab20013d6820ef5a5c2f7ff4%2F_.debug’ saved [118073560/118073560]

that's a ~176% difference in transfer rate compared to .NET SDK blob download.

Please move the symstore blobs under the similar CDN plan as .NET SDK, so .NET developers worldwide can use the diagnostic tools.

Thanks.

[am11]

cc @mikem8361

Regarding explicit timeout of 4 minutes; is there a reason for this? (e.g. some time bound operation will go wrong if the file arrives late or some such?)

If it is just for better UX, maybe we can set the timeout to infinity/max by default, and show progress bar dotnet/runtime#16681 (comment) to improve the quality of UX.

[mikem8361]

Adding a --timeout option to dotnet-symbol.

[am11]

With --timeout of 20 minutes, I got Error while copying content to a stream:

$ dotnet symbol --symbols mysinglefilehostapp1 --timeout 20
Downloading from http://msdl.microsoft.com/download/symbols/
ERROR: HttpSymbolStore: Error while copying content to a stream. singlefilehost.dbg - 'http://msdl.microsoft.com/download/symbols/_.debug/elf-buildid-sym-27997343859af70e0bfc5e50a4d1059b3513a1c4/_.debug'

With wget or opening this URL in browser, it downloads the file successfully.

[am11]

Second attempt (after once downloaded with browser; likely cached by ISP) worked.
Note: i had to apply fix from #258 in both; failure and success cases to avoid a prompt 404 response.

[mikem8361]

This should be fixed with dotnet-symbol version 1.0.212301 I just released.