CDN ) CDN 결과 비교하기, 근데 거기에 Request header 분석을 곁들인...

✅ 개인 공부용으로 작성한 글입니다 :)

 

 

요청한 파일

서버에 요청한 파일로  camera.glb (11.5MB)의 3d 모델링 파일을 불러왔다. 모델링의 나름대로 디테일이 많아 꽤 큰 용량의 파일이다.

nodejs 서버의 static 으로 불러오는 방법과, cdn을 거쳐서 불러오는 방법의 속도차를 비교하려한다.

*3d 파일을 babylon.js로 랜더링하는 경우 load가 어떻게 이뤄지는지는 확인해봐야함. → 프론트 개발자분께 요청드려야겠다.

 

바빌론 에디터에서 https로 파일을 불러오는 코드를 사용해 테스트 해보았다.

 

CDN이 무엇이냐

CDN은 ATM과 같다고 봐도 된다.

CDN을 설명하는 최고의 문장인듯.

일반 도메인으로 요청을 하면, 원본 파일이 있는 서버에 요청을 하는데, 만약 원본 서버가 미국에 있고 사용자가 한국에서 이미지 파일을 요청하면 시간이 꽤 걸리게 된다. 이때 이러한 "느린 전송"을 방지하기 위해 CDN을 사용한다. 사용자가 Request하는 위치와 가까운 프록시 서버에 요청하는 방법이 CDN이다. 가장 가까운 ATM(여기선 CDN)기기를 찾아가 나 이 파일 주세요 띡띡 요청하는 방식이라고 이해하면 된다.

CDN이라고 마냥 좋은 것은 아니라 한다. 특정 지역이나, 국가에 제공할 서비스라면 CDN을 적용할시 불필요한 캐시를 날리고, 의미없는 프록시 서버만 늘어나는 거라 굳이 굳이 라고...

→ 이 부분은 좀더 알아봐야겠다. 요청하는 파일이 클 경우, 클라이언트 로드 속도를 줄이기위한 정책으로 활용할 수 있는지 멘토님께 여쭤봐야지.

 

https://www.akamai.com/ko/our-thinking/cdn/what-is-a-cdn

https://library.gabia.com/contents/infrahosting/8985/

 

CDN 없이 static 파일로 불러온 경우

 

CDN 없이 요청한 경우
Resource Scheduling / Queueing	1.17ms
Connection Start / Stalled	1.25ms
Request sent	42 µm
waiting (TTFB)	10.88ms
Content Download	309.71ms
Total	323.04

 

 

CDN으로 파일로 불러온 경우

CDN 으로 요청한 경우
Resource Scheduling / Queueing	1.96ms
Connection Start / Stalled	1.75ms
Request sent	0.12ms
waiting (TTFB)	13.17ms
Content Download	244.25ms
Total	361.25 ms

 

 

한눈에 비교하기

	CDN (x)	CDN (o)
Queued at	891.38 ms	731.54 ms
Started at	892.54 ms	733.50 ms
Resource Scheduling / Queueing	1.17 ms	1.96 ms
Connection Start / Stalled	1.25 ms	1.75 ms
Request sent	42 µm	0.12 ms
waiting (TTFB)	10.88 ms	13.17 ms
Content Download	309.71 ms	244.25 ms
Total	323.04 ms	261.25 ms

오히려 큐잉이나, 리퀘스트 보내는 시간은 조금 더 걸렸고, Content Download에서 시간을 줄일 수 있었다.

지금은 11MB밖에 안하지만, 맵이 커지면 커질수록 용량을 장담할 수 없기 때문에 cdn으로 요청하는 편이 좋겠다. 

 

Network Timing 탭 항목 설명

• Queued at : 개발자 도구를 켠 순간부터 큐에 쌓이는데 까지 걸리는 시간
• Started at : 개발자 도구를 켠 순간부터 request 를 보내는데 까지 걸리는 시간
• Queueing : 구문 분석한 시점에서 큐에 넣는데 그게 적재 되어 있는 시간 (?)
• Stalled : 큐에서 request를 보내는데 그게 정지되어 있는 시간
• Proxy negotiation : 브라우저가 프록시 서버로 요청을 보내는데까지 걸리는 시간
• Request sent : request를 보내는데 걸리는 시간
• Waiting (TTFB) : response의 첫 번째 바이트가 도달하는데까지 기다린 시간 (Time To First Byte)
• Content Download : content가 다운로드가 되는데 까지 기다린 시간. 시작 시점은 response 시작 시점, 종료 시점은 response 종료시점이라 생각해도 무방
• total = Explanation 

 

 

 

 

▼ 원본 블로그

https://velog.io/@ysh1394/TIL-No.8-Chrome%EA%B0%9C%EB%B0%9C%EC%9E%90-%EB%8F%84%EA%B5%AC-Network-%ED%8C%A8%EB%84%90%EC%9D%98-%EA%B8%B0%EB%8A%A5

TIL No.8 [Chrome]개발자 도구 Network 패널의 기능