Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 

Visual Studio의 느린 업데이트 속도에 대한 원인 분석

아래의 그림은,

vs_download_update_1.png

42KB/sec 속도로 업데이트하는 회사의 컴퓨터와, 204KB/sec 속도로 업데이트하는 집의 컴퓨터 상황입니다. 640MB와 4.3GB를 받느라 몇 시간을 소요했는지... ^^; 최근 들어 이런 업데이트 속도가 나오는데 심각하군요. 사실 더욱 문제는 이렇게 업데이트를 하는 동안 Visual Studio가 실행되지 않으므로 아무런 작업도 할 수 없다는 점입니다.

게다가, 켜놓고 퇴근한다고 해서 해결되지도 않습니다. 왜냐하면, 업데이트하는 도중 특정 패키지는 유독 용량이 커서 그런지 다음과 같은 오류 메시지를 내며 창이 떠서,

After nine attempts, there was a problem downloading the following file:
https://download.visualstudio.microsoft.com/download/pr/20628b98-6f1d-4b37-90d8-e844e82b4c81/3a8f58701674c8309cb67914e703d48918c27a42db4b4226037af63389cc3245/dotnet-sdk-internal-3.1.301-win-x64.msi

Select Continue to install Visual Studio without downloading this file. This might cause problems with other parts of the installation.

Select Retry to try downloading the file again.

Select Cancel to cancel the Visual Studio install.

[Get help installing behind a firewall or proxy server.](https://go.microsoft.com/fwlink/?linkid=872312)

사용자가 (화면 앞에 앉아서) "Retry" 버튼을 눌러줘야만 다시 다운로드를 반복합니다. 하지만, 이미 속도가 느린 상황에서 다시 다운로드한다고 성공한다는 보장이 없습니다. 운이 나쁘면 하나의 패키지를 몇 번을 반복하며 Retry 버튼을 눌러야 하는 경우도 생깁니다.




이에 대한 가장 좋은 해결책은, 외부 VPN을 사용하는 것입니다. 검색해 보면 일본의 VPN을 사용해서 속도를 높였다는 글이 나오고, 제가 아는 어떤 분은 아예 ExpressVPN을 결제해서 사용한다고도 합니다.

재미있는 것은, 이 문제가 꼭 마이크로소프트의 다운로드 서버에 있다고 장담할 수 없다는 것입니다. 왜냐하면, 제 경우에는 국내의 Azure 데이터 센터 중에서 "KoreaCentral"에 위치한 VM에 OpenVPN을 설치해서,

윈도우에 OpenVPN 설치 - 서버 측 구성
; https://www.sysnet.pe.kr/2/0/12224

연결했더니, 다음과 같이 다운로드 속도가 수 MB/sec로 올라왔습니다.

vs_download_update_2.png

만약 마이크로소프트 측의 다운로드 서버가 문제였다면 저런 현상은 설명하기 힘듭니다. (좀 더 자세한 분석은 잠시 뒤로 미루겠습니다. ^^)




만약 외부 VPN을 사용할 수 없다면, 다운로드하는 동안 업무를 지속할 수 있게 설치 옵션을 변경하는 것이 권장됩니다. 비주얼 스튜디오의 경우 "Install while downloading(다운로드하는 동안 설치)", "Download all, then install(모두 다운로드한 후 설치)" 2개의 옵션을 설정할 수 있도록 하는데 전자의 경우가 기본값이기 때문에 일부러 두 번째 옵션으로 변경해 주어야 합니다.

그런데, 여기서 주의할 것은 아래의 화면 단계에서,

vs_download_update_3.png

변경하는 것은 소용이 없습니다. 저건 이미 설치된 구성 요소들 중에서 선택/해제를 통해 변경할 경우에 한해서이고, 업데이트를 받는 것은 다음과 같은 화면에서,

vs_download_update_4.png

나오는 옵션 중에서 "다운로드 후 업데이트"를 선택해야만 합니다.




참고로, 하나의 PC에서 바이너리를 다운로드해 다른 PC에서도 재사용할 수 있는 옵션이 있긴 합니다.

Create an offline installation of Visual Studio
; https://docs.microsoft.com/ko-kr/visualstudio/install/create-an-offline-installation-of-visual-studio

하지만, 이런 식의 local cache는 전체 구성 요소를 다운로드하는 데 이것의 용량이 최소 35GB라고 합니다. 아니... 지금 650MB도 몇 시간에 걸쳐서 "Retry" 버튼을 눌러가며 진행하는데 35GB를 어느 세월에 다 받으라는 것입니까? ^^;

찾아 보면 자신의 PC에 설치한 비주얼 스튜디오의 구성 요소를 export시킬 수는 있는데,

Command-line parameter examples for Visual Studio installation
; https://docs.microsoft.com/ko-kr/visualstudio/install/command-line-parameter-examples?view=vs-2019

// test.vsconfig 파일에 현재 설치한 구성 요소 목록을 출력

cd "C:\Program Files (x86)\Microsoft Visual Studio\Installer"
vs_installer export --installPath "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise" --config "C:\temp\test.vsconfig"

이 목록을 local cache를 만드는 "--layout"에 전달하는 옵션은 없으므로 헛수고에 불과합니다.




어쨌든... 현상은 그렇다 치고, 이제 약간의 문제 분석을 해보겠습니다. 우선 집에서 다운로드를 할 때의 "download.visualstudio.microsoft.com" 도메인 주소는 "192.229.232.200"이고 다음은 ping과 tracert에 대한 결과입니다.

C:\> ping 192.229.232.200

Pinging 192.229.232.200 with 32 bytes of data:
Reply from 192.229.232.200: bytes=32 time=86ms TTL=52
Reply from 192.229.232.200: bytes=32 time=86ms TTL=52
Reply from 192.229.232.200: bytes=32 time=85ms TTL=52
Reply from 192.229.232.200: bytes=32 time=86ms TTL=52

Ping statistics for 192.229.232.200:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 85ms, Maximum = 86ms, Average = 85ms

C:\> tracert 192.229.232.200

Tracing route to 192.229.232.200 over a maximum of 30 hops

  1     3 ms     3 ms     4 ms  210.91.106.126
  2   120 ms     4 ms     2 ms  14.53.87.77
  3     2 ms    <1 ms     1 ms  112.188.86.57
  4     3 ms     3 ms     7 ms  112.188.77.41
  5     *        *        *     Request timed out.
  6     2 ms     3 ms     3 ms  112.174.81.42
  7    22 ms     1 ms     2 ms  112.174.83.30
  8    78 ms    80 ms    84 ms  209-8-177-5.static.pccwglobal.net [209.8.177.5]
  9    84 ms    84 ms    81 ms  HundredGE0-5-0-1.br02.tok02.pccwbtn.net [63.218.250.165]
 10    84 ms    84 ms    84 ms  63.218.251.210
 11    87 ms    94 ms     *     ae-65.core1.tkb.edgecastcdn.net [152.195.112.131]
 12     *       85 ms    86 ms  192.229.232.200

Trace complete.

반면 KoreaCentral에 위치한 VPN 서버에서 동일하게 ping과 tracert를 하면, 다음과 같이 나옵니다.

C:\> ping 192.229.232.200

Pinging 192.229.232.200 with 32 bytes of data:
Reply from 192.229.232.200: bytes=32 time=30ms TTL=50
Reply from 192.229.232.200: bytes=32 time=30ms TTL=50
Reply from 192.229.232.200: bytes=32 time=30ms TTL=50
Reply from 192.229.232.200: bytes=32 time=30ms TTL=50

Ping statistics for 192.229.232.200:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 30ms, Maximum = 30ms, Average = 30ms

C:\> tracert 192.229.232.200

Tracing route to 192.229.232.200 over a maximum of 30 hops

  1     *        *        *     Request timed out.
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.
  7     *        *        *     Request timed out.
  8     *        *        *     Request timed out.
  9     *        *        *     Request timed out.
 10     *        *        *     Request timed out.
 11     *        *        *     Request timed out.
 12     *        *        *     Request timed out.
 13     *        *        *     Request timed out.
 14    30 ms    30 ms    31 ms  192.229.232.200

Trace complete.

저걸 보면, 분명히 업데이트 파일을 제공하는 마이크로소프트 측의 서버가 잘못된 것은 아닐 거라는 추측을 할 수 있습니다. 그렇다면, 이제 집에서 KoreaCentral에 위치한 VPN 서버까지의 ping과 tracert 결과를 봐야 하는데요,

C:\> ping sysnet.koreacentral.cloudapp.azure.com

Pinging sysnet.koreacentral.cloudapp.azure.com [52.231.8.55] with 32 bytes of data:
Reply from 52.231.8.55: bytes=32 time=4ms TTL=115
Reply from 52.231.8.55: bytes=32 time=4ms TTL=115
Reply from 52.231.8.55: bytes=32 time=6ms TTL=115
Reply from 52.231.8.55: bytes=32 time=4ms TTL=115

Ping statistics for 52.231.8.55:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 4ms, Maximum = 6ms, Average = 4ms


C:\> tracert sysnet.koreacentral.cloudapp.azure.com

Tracing route to sysnet.koreacentral.cloudapp.azure.com [52.231.8.55]
over a maximum of 30 hops:

  1     9 ms     5 ms     4 ms  210.91.106.126
  2     5 ms     8 ms     4 ms  14.53.87.77
  3     2 ms    <1 ms     2 ms  112.188.86.57
  4     2 ms     7 ms     4 ms  112.188.78.41
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.
  7    47 ms    11 ms     3 ms  121.189.3.138
  8    10 ms     6 ms     4 ms  ae29-0.icr02.sel21.ntwk.msn.net [104.44.239.244]
  9     *        *        *     Request timed out.
 10     *        *        *     Request timed out.
 11     *        *        *     Request timed out.
 12     *        *        *     Request timed out.
 13     *        *        *     Request timed out.
 14     *        *        *     Request timed out.
 15     *        *        *     Request timed out.
 16     *        *        *     Request timed out.
 17     *        *        *     Request timed out.
 18     *        *        *     Request timed out.
 19     3 ms     6 ms     4 ms  52.231.8.55

Trace complete.

보는 바와 같이 매우 빠릅니다. 결국, 문제의 원인은 국내 ISP 업체(여기서는 KT)가 112.174.83.30에서 209.8.177.5 측으로 라우팅하는 설정이 네트워크를 느리게 만든 주요 원인입니다. 실제로 집이나 회사에서 209.8.177.5로 직접 ping을 해보면,

C:\> ping 209.8.177.5

Pinging 209.8.177.5 with 32 bytes of data:
Reply from 209.8.177.5: bytes=32 time=82ms TTL=248
Reply from 209.8.177.5: bytes=32 time=84ms TTL=248
Reply from 209.8.177.5: bytes=32 time=84ms TTL=248
Reply from 209.8.177.5: bytes=32 time=84ms TTL=248

Ping statistics for 209.8.177.5:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 82ms, Maximum = 84ms, Average = 83ms

마이크로소프트의 다운로드 서버(52.231.8.55)까지 가는 대부분의 지연 시간을 담당하고 있음을 보여줍니다. (물론, KoreaCentral에 있는 Azure 데이터 센터에서는 그쪽으로의 라우팅을 하지 않기 때문에 빨랐던 것이고.)

그렇다면, KT에서 선택한 그 209.8.177.5 라우팅은 다른 대안이 없었던 것일까요? 아니면 그 업체에서의 회선 대여료가 저렴해 그쪽으로만 한 것일까요?... 이런 부분은 KT의 엔지니어가 아니면 답할 수 없는 부분이니 더 이상의 분석은 의미가 없게 됩니다.




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]





[최초 등록일: ]
[최종 수정일: 6/13/2020 ]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer@outlook.com

비밀번호

댓글 쓴 사람
 



2020-06-13 10시26분
[jacking75] 이 문제는 한국MS에서 해결해줘야 하는데 아무것도 안하고 있는 것 같아서 더 불만스럽습니다. 만약 뭔가 해결 행동을 하고 있다면 공유를 해주었으면 하네요.
[손님]
2020-06-15 06시29분
[shseo] 정보 감사합니다. 포맷 후에 재설치 중인데, 하루 종일 걸리네요. 6월 15일 현재 여전히 느리네요...
[손님]
2020-06-16 12시01분
[정환나라] kt회선 사용일 경우 hosts파일에
93.184.215.201 download.visualstudio.microsoft.com
을 추가하시면 됩니다
[손님]
2020-06-16 12시14분
@정환나라 알려주신 방법이 잘 되는군요. ^^ 재미있게도 tracert를 하면 시간이 더 걸리는데, 그래도 빠른 걸로 봐서는 꼭 tracert의 결과가 속도와 직접적인 상관이 있다고 단정지어서는 안 되나 봅니다.

C:\> tracert 93.184.215.201

Tracing route to download.visualstudio.microsoft.com [93.184.215.201]
over a maximum of 30 hops:

  1 4 ms 2 ms 2 ms 210.91.106.126
  2 4 ms 3 ms 4 ms 14.53.87.77
  3 2 ms <1 ms <1 ms 112.188.86.57
  4 2 ms 2 ms 6 ms 112.188.78.25
  5 * * * Request timed out.
  6 43 ms 27 ms 24 ms 112.174.82.114
  7 8 ms 8 ms 8 ms 112.174.85.154
  8 128 ms 128 ms 128 ms 112.174.89.254
  9 192 ms 193 ms 193 ms edgecastcdn.net [198.32.160.115]
 10 192 ms 192 ms 193 ms ae-65.core1.nyb.edgecastcdn.net [152.195.68.131]
 11 191 ms 191 ms 190 ms download.visualstudio.microsoft.com [93.184.215.201]

Trace complete.
정성태
2020-06-16 10시36분
[이성환] 와아! 지난주부터 이거 때문에 골치아팠는데 꿀팁 감사합니다!
[손님]

1  2  3  4  5  6  [7]  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
12286정성태8/5/2020322개발 환경 구성: 501. .NET Core 용 container 이미지 만들 때 unzip이 필요한 경우
12285정성태8/4/2020543오류 유형: 635. 윈도우 10 업데이트 - 0xc1900209 [2]
12284정성태8/26/2020529디버깅 기술: 169. Hyper-V의 VM에 대한 메모리 덤프를 뜨는 방법
12283정성태8/3/2020324디버깅 기술: 168. windbg - 필터 드라이버 확인하는 확장 명령어(!fltkd)
12282정성태8/2/2020275디버깅 기술: 167. windbg 디버깅 사례: AppDomain 간의 static 변수 사용으로 인한 crash (2)
12281정성태8/2/2020493개발 환경 구성: 500. (PDB 연결이 없는) DLL의 소스 코드 디버깅을 dotPeek 도구로 해결하는 방법
12280정성태8/2/2020466오류 유형: 634. 오라클 (평생) 무료 클라우드 VM 생성 후 SSH 접속 시 키 오류 발생
12279정성태7/29/2020299개발 환경 구성: 499. 닷넷에서 접근해보는 InterSystems의 Cache 데이터베이스파일 다운로드1
12278정성태8/2/2020267VS.NET IDE: 149. ("Binary was not built with debug information" 상태로) 소스 코드 디버깅이 안되는 경우
12277정성태8/2/2020459개발 환경 구성: 498. DEVPATH 환경 변수의 사용 예 - .NET Reflector의 (PDB 연결이 없는) DLL의 소스 코드 디버깅
12276정성태7/23/2020443.NET Framework: 930. 개발자를 위한 닷넷 어셈블리 바인딩 - DEVPATH 환경 변수
12275정성태7/28/2020379개발 환경 구성: 497. 닷넷에서 접근해보는 InterSystems의 IRIS Data Platform 데이터베이스파일 다운로드1
12274정성태7/21/2020404개발 환경 구성: 496. Azure - Blob Storage Account의 Location 이전 방법파일 다운로드1
12273정성태7/20/2020504개발 환경 구성: 495. Azure - Location이 다른 웹/DB 서버의 경우 발생하는 성능 하락
12272정성태7/16/2020314.NET Framework: 929. (StrongName의 버전 구분이 필요 없는) .NET Core 어셈블리 바인딩 규칙파일 다운로드1
12271정성태7/16/2020341.NET Framework: 928. .NET Framework의 Strong-named 어셈블리 바인딩 (2) - 런타임에 바인딩 리디렉션파일 다운로드1
12270정성태7/16/2020493오류 유형: 633. SSL_CTX_use_certificate_file - error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small
12269정성태7/16/2020282오류 유형: 632. .NET Core 웹 응용 프로그램 - The process was terminated due to an unhandled exception.
12268정성태7/15/2020351오류 유형: 631. .NET Core 웹 응용 프로그램 오류 - HTTP Error 500.35 - ANCM Multiple In-Process Applications in same Process
12267정성태7/15/2020525.NET Framework: 927. C# - 윈도우 프로그램에서 Credential Manager를 이용한 보안 정보 저장파일 다운로드1
12266정성태7/14/2020420오류 유형: 630. 사용자 계정을 지정해 CreateService API로 서비스를 등록한 경우 "Error 1069: The service did not start due to a logon failure." 오류발생
12265정성태7/10/2020261오류 유형: 629. Visual Studio - 웹 애플리케이션 실행 시 "Unable to connect to web server 'IIS Express'." 오류 발생
12264정성태7/9/2020377오류 유형: 628. docker: Error response from daemon: Conflict. The container name "..." is already in use by container "...".
12261정성태9/26/2020770VS.NET IDE: 148. 윈도우 10에서 .NET Core 응용 프로그램을 리눅스 환경에서 실행하는 2가지 방법 - docker, WSL 2 [5]
12260정성태7/8/2020341.NET Framework: 926. C# - ETW를 이용한 ThreadPool 스레드 감시파일 다운로드1
12259정성태7/8/2020273오류 유형: 627. nvlddmkm.sys의 BAD_POOL_HEADER BSOD 문제
1  2  3  4  5  6  [7]  8  9  10  11  12  13  14  15  ...