[C1]웹서비스, 빠를수록 좋다

5,550 views

Published on

1 Comment
18 Likes
Statistics
Notes
  • 우리 프로젝트 팀에게 제일 먼저 보여줘야 겠다.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
5,550
On SlideShare
0
From Embeds
0
Number of Embeds
2,505
Actions
Shares
0
Downloads
190
Comments
1
Likes
18
Embeds 0
No embeds

No notes for slide

[C1]웹서비스, 빠를수록 좋다

  1. 1. 웹서비스, 빠를수록 좋다
  2. 2. 성능엔지니어링랩 @NHN 김일환  성능에 대한 A-to-Z  분산처리, OS, TCP/IP  Performance-as-a- feature  NHN Thruput, Scalability, Latency, 인프라 아키텍처랩장 Availability… IT서비스 기획실장  Back-end  front-end 성능 아키텍트 서버, 네트워크, noSQL 웹 / 모바일 서비스 성능  Front-end 브라우저 / 네트워크 성능 브라우저, 네트워크, UI
  3. 3. 0.66sec
  4. 4. 1sec
  5. 5. Steven C. Seow심리학 박사Microsoft
  6. 6. 순간적 <0.2초 (200ms)  눈 깜짝할 사이  클릭  메뉴 펼쳐지는 시간  액션게임 반응시간: 타겟 인식  발사
  7. 7. 즉시 <1초  Flow = 몰입 상태의 지속  책장을 넘기는 시간  PageDn, Wheel Scroll
  8. 8. 연속적 <5초  일시적으로 몰입상태를 벗어남  몰입상태로 쉽게 되돌아갈 수 있음  다른 창을 띄우거나 딴 짓은 못하는 시간
  9. 9. 참고 기다림 <10초  짜증나지만 참고 기다릴 수 있음  사용자가 다른 작업으로 switching하기 시작
  10. 10. Satisfaction = Perception - Expectation http://davidmaister.com/articles/5/52/
  11. 11. 웹 서비스에 대한사용자들의 기대수준과 만족도
  12. 12. 목적형 서비스 (검색, 슬라이드쇼, 메일, 사전, 날씨)2-3초를 넘어가면 만족률 < 50% 모바일 웹 85.3 PC 웹 73.8 89.4 60.3 78.9만족률 = 50% 44.5 61.1 41.75점 만점4-5점 응답자 비율 45.6 13.8 25.0 11.1 0.5 1 2 3 4 5 10 Source: NHN UX랩
  13. 13. 서핑형 서비스 (뉴스, 카페, 블로그, 웹툰, 영화)과반수는 4-5초까지 기다릴 수 있음 모바일 웹 94.3 93.6 85.6 PC 웹 69.0 63.2 80.5 55.2 79.5만족률 = 50% 68.85점 만점4-5점 응답자 비율 41.0 20.8 17.6 0.5 1 2 3 4 5 10 Source: NHN UX랩
  14. 14. 1. 체감시간은 성능 + 디자인에 좌우  색상, progress bar, progressive rendering, 마우스 버벅임 등  기다리는 동안 즐길거리가 제공되는가?2. 만족도는 기대수준에 반비례  목적형 서비스: 2-3초 이내  서핑형 서비스: 4-5초 이내
  15. 15. 1인당 PV vs. 로딩속도 High End300 High Mid Low Mid250 Low End20015010050 0 1 2 3 4 5 6 7 8 9 10 로딩속도 (초) High Mid: Dual core 2.4G 급 Source: NHN 데이터정보센터 Low Mid: Pentium 4 3G 급
  16. 16. 실험: 고의적인 서버 딜레이 주입 서버 딜레이 주입 딜레이 제거 후에도 회복 안됨 0.2%대조 -0.08%군 0%대비 - 0.2% -0.36% -0.21%1인당 - 0.4%검색 - 0.6%량저 - 0.8% : 0.2s하 -0.74%율 - 1.0% : 0.4s 3주 4주 5주 6주 7주 8주 9주 10주 11주 Source : Performance Related Changes and their User Impact (Eric Schurman, Principal Development Lead, Bing; Jake Brutlag Decision Support Engineering Analyst, Google)
  17. 17. 1초 딜레이 = 매출 ⇩ 3% 1인당 검색링크 1인당 QC 1인당 매출 재검색 수 클릭 수0.05s - - - -0.2s - - - -0.3%0.5s - -0.6% -1.2% -1.0% 1s -0.7% -0.9% -2.8% -1.9% 2s -1.8% -2.1% -4.3% -4.4% Source : Performance Related Changes and their User Impact (Eric Schurman, Principal Development Lead, Bing; Jake Brutlag Decision Support Engineering Analyst, Google)
  18. 18. 왜 그럴까?
  19. 19. 나쁜 사용자경험 만족도 저하 재방문 기피 PV 하락 매출 저하
  20. 20. 나쁜 사용자경험  만족도 저하  재방문 기피  PV 하락  매출 저하당연한 거 아님?님 바보? ㅋㅋ
  21. 21. 로딩 = 수천만 사용자가 멍때리는 낭비하는 시간 검색결과 랜딩페이지 검색 로딩 로딩 열람 열람
  22. 22. 검색결과 페이지검색 로딩 로딩 열람 열람 로 로 딩 딩 로 검색결과 로 페이지 열검색 딩 열람 딩 람
  23. 23. 검색결과 페이지검색 로딩 로딩 열람 열람 로 로 딩 딩 로 검색결과 로 페이지 열 로 추가 로 추가검색 딩 열람 딩 람 딩 PV 딩 PV
  24. 24. 0.1초는 체감하기 힘든 짧은 시간, 하지만……1. 로딩시간을 줄이면 전체 사용자의 총 가처분 시간이 늘어난다2. 가처분 시간이 늘어나면 결국 사용자와 웹 생태계 모두의 이득∴ 단 0.1초라도 빠를수록 좋다!
  25. 25.  Navigation Timing API  window.performance.timing  지원: IE 9+, FF7+, Chrome 6+ Web Performance WG: http://www.w3.org/2010/webperf/
  26. 26. 로딩끝 onload()로딩시작onunload()onclick() Web Performance WG: http://www.w3.org/2010/webperf/
  27. 27. 실제 사용자의 매 PV별 속도 집계장점 단점 가장 정확한 현실 출시 사후에만 측정 가능 전체 PV 샘플링 상세 원인분석 불가 구현체  nav timing API, boomerang.js  $$$: torbit.com, CorrelSense, Google Analytics…  DIY: piwik.org, stathat.com, StatD, Graphite…
  28. 28. 인위적으로 구성된 네트워크 + Agent로 랩 테스트 IDC 또는 가정집에 설치한 agent에서 측정 변수통제: 네트워크/PC 배경부하, 캐시 상세분석: TTFB, Waterfall, 시각성능(RST, AFT) 모니터링 구현체  $$$: Gomez, Keynote  DIY: WebPageTest
  29. 29. 인위적으로 구성된 네트워크 + Agent로 랩 테스트 과연 내 서비스 사용자 환경과 같을까? 대표성이 있을까?
  30. 30. Track F / 16:30~17:10 http://me2.do/50rkntO Synthetic Measurement tool 네이버 사용자 환경 재현 테스트  Calibrated test network & agent  Desktop and mobile support  Waterfall, filmstrip, regression
  31. 31. 웹 개발자 입장에서 보면… 단순 투자로는 개선 불가DataCenter노력하면 효율화 가능 NW, HW, OS, Browser공급자 콘텐츠 마크업 서버디자인 UI코드 성능 사용자 콘텐츠
  32. 32. Peak 대비 200% 이상의 headroom 용량 확보장애에 대응하기 위한 이중화 및 overprovisioningDataCenter
  33. 33. 사용자 환경NW, HW, OS, Browser사용자 콘텐츠
  34. 34. 가입자당 최대속도: 평균 50Mbps, 그러나… “The State of the Internet”, 2012Q1, Akamai
  35. 35. 4Mbps 이하 가입자가 14% 한국 가입자 속도분포 14% >10Mb 53% 4~10Mb 33% <4Mb “The State of the Internet”, 2012Q1, Akamai
  36. 36. 대역폭이 5M 있어도 2.5M 밖에 쓰지 못함 실제로 웹브라우저가 쓰는 유효대역폭은 RTT에 반비례 왜 다 쓰지를 못하니?  TCP handshake  TCP slowstart  Browser blocking http://www.belshe.com/2010/05/24/more-bandwidth-doesnt- matter-much/
  37. 37. Track C / 15:40~16:20 웹/앱 개발자 입장에서 궁금한 모바일 네트워크의 속사정  3G 네트워크의 latency 문제  TCP/HTTP 성능저하의 이유  RRC state transition http://me2.do/FzTGenF
  38. 38. 저사양 사용자 30%, 2.5배까지 느려짐 CPU 등급 분포 네이버 전체 평균 (초) 6.0 High end 8% High mid 5.0 Low mid 4.0 28% 21% Low end 3.0 2.0 43% 1.0 0.0High mid: dualcore 2.4GHz 급 High High Low LowLow mid: P4 3GHz 급 End Mid Mid End
  39. 39. IE6,7 PV 비중은 15%, 1.7배 느려짐 브라우저별 PV 점유율 네이버 전체 평균(초) 4.0 4% 3.5 1% 8% IE8 3.0 IE9 2.5 11% 47% IE7 2.0 chrome 1.5 29% IE6 1.0 기타 0.5 0.0 IE 9 IE 8 IE 7 IE 6
  40. 40. 노력하면 효율화 가능공급자 콘텐츠 마크업 서버디자인 UI코드 성능
  41. 41. 로딩시간과의 상관관계 (Correlation)0.80.7 0.730.6 0.65 0.63 0.590.50.4 0.420.30.20.1 0 총용량 이미지용량 총 건수 이미지 건수 js 용량 2012/9, http://httparchive.org
  42. 42. ※ 사용자 환경과 콘텐츠가 크게 다르기 때문에 로딩속도 상대비교는 배제 웹페이지 총 용량 (MB)3.5 3.2 32.5 국내T100 2 국내포털1.5 해외전체 1.1 1 해외T100 1 0.60.5 0 2012/9 랭키닷컴 상위 100 사이트 http://httparchive.org
  43. 43. 총 1.5MB 이하, 리소스 200개 이하, 웹 폰트 사용배제 3s~네이버 서비스별 리소스 현황 2~3sRequest (단위: 개) ~2s400 (4.9s)300 (3.0s) (1.7s)200 (3.3s) (5.1s) (3.8s) (1.7s) (3.1s) (4.1s) (1.8s)100 (3.5s) (2.8s) (1.5s) (2.4s) (3.5s) 0 0 500 1,000 1,500 2,000 2,500 3,000 3,500 Size (단위: KB)
  44. 44. 1. 갑, 기획자, 디자이너, 개발자의 의기투합  Speed = PV = $$$  “사용자에게 꼭 필요한 것만 넣자”2. 실사용자 속도 측정  RUM 또는 calibrated test  개발자 PC는 일반적으로 실사용자 PC보다 훨씬 빠르므로 *주의*3. 웹 최적화에 시간 할애하기  프로젝트, 유지보수 공수에 산입  기초적인 WPO 적용4. Goto 1.
  45. 45.  Steve Souders “바이블”  쉽다  얇다  한글판도 있다 자동 진단 도구  Yslow, Pagespeed 자동 최적화 도구  mod_pagespeed
  46. 46. 불필요한 정보 제거 btn_moviepage_left_on.gif미사용 이미지, 중복 이미지 btn_prev2.gif 미사용 css 이미지 중복 이미지미사용 css, js 코드웹폰트 – 2MB나 되므로 효율성 제고주석문, 공백, 너무 긴 변수명  “Minify” built in build machinegzip 압축 전송 적용  압축-해제 비용보다 이득이 훨씬 많음
  47. 47. 이미지 용량 낭비 = 네트워크 비용 낭비크기에 맞게 서버에서 리사이즈한 후 내려주기  <img width=xxx height=yyy> 태그 리사이즈 금지이미지 최적화  불필요한 메타정보 삭제 (Exif, embedded thumbnail)  적절한 포맷(PNG/GIF/JPG) 및 압축률 선택  Tools: Image optimizer, Smush.it, Kraken, …
  48. 48. CSS Sprite 여러 이미지를 한 개의 sprite로 병합 공수가 많이 들지만 매우 효과적 http://spriteme.org/
  49. 49. Expires, Cache-control: max-age 헤더  생략하면 불필요한 conditional GET(304) 요청 유발Last-modified 헤더  생략하면 GET If-Modified-Since 대신 무조건 GET(200) 요청Etag 헤더  동일 URL에 대해 서로 다른 Etag가 붙어오지 않는지 확인권장 사항  Etag 미사용, Last-Modified + Expires 필수
  50. 50. CSS는 위로, JS는 아래로 CSS는 렌더링에 필수적이므로 html 가장 위에 배치 JS는 브라우저를 block 시키므로 가급적 아래쪽에 배치 Js 로딩 파싱 blocking으로 인한 이미지 로딩 지연
  51. 51. 2층 소회의실18:30-19:30 Nspeed 데모 웹 페이지 최적화 네트워크 성능 브라우저 성능 Off-the-record 수다떨기

×