웹서비스, 빠를수록 좋다

성능엔지니어링랩 @NHN

성능에 대한 A-to-Z

Performance-as-a- feature

Thruput, Scalability, Latency,

Availability…

Back-end

서버, 네트워크, noSQL

Front-end

브라우저, 네트워크, UI

김일환

분산처리, OS, TCP/IP

NHN

인프라 아키텍처랩장

IT서비스 기획실장

front-end 성능 아키텍트

웹 / 모바일 서비스 성능

브라우저 / 네트워크 성능

0.66sec

1sec

http://me2.do/line

Steven C. Seow

심리학 박사

Microsoft

순간적 <0.2초 (200ms)

눈 깜짝할 사이

클릭 메뉴 펼쳐지는 시간

액션게임 반응시간: 타겟 인식 발사

즉시 <1초

Flow = 몰입 상태의 지속

책장을 넘기는 시간

PageDn, Wheel Scroll

연속적 <5초

일시적으로 몰입상태를 벗어남

몰입상태로 쉽게 되돌아갈 수 있음

다른 창을 띄우거나 딴 짓은 못하는 시간

참고 기다림 <10초

짜증나지만 참고 기다릴 수 있음

사용자가 다른 작업으로 switching하기 시작

Satisfaction =

Perception - Expectation

http://davidmaister.com/articles/5/52/

웹 서비스에 대한

사용자들의 기대수준과 만족도

2-3초를 넘어가면 만족률 < 50%

목적형 서비스 (검색, 슬라이드쇼, 메일, 사전, 날씨)

85.3

73.8

60.3

44.5 41.7

13.8

89.4 78.9

61.1

45.6

25.0 11.1

0.5 1 2 3 4 5 10

모바일 웹

PC 웹

만족률 = 50%

Source: NHN UX랩

5점 만점 4-5점 응답자 비율

과반수는 4-5초까지 기다릴 수 있음

서핑형 서비스 (뉴스, 카페, 블로그, 웹툰, 영화)

93.6 85.6

68.8

63.2 55.2

20.8

94.3

80.5 79.5

69.0

41.0

17.6

0.5 1 2 3 4 5 10

모바일 웹

PC 웹

만족률 = 50%

Source: NHN UX랩

5점 만점 4-5점 응답자 비율

1. 체감시간은 성능 + 디자인에 좌우

색상, progress bar, progressive rendering, 마우스 버벅임 등

기다리는 동안 즐길거리가 제공되는가?

2. 만족도는 기대수준에 반비례

목적형 서비스: 2-3초 이내

서핑형 서비스: 4-5초 이내

http://me2.do/line

Source: NHN 데이터정보센터

0

50

100

150

200

250

300

1 2 3 4 5 6 7 8 9 10

로딩속도 (초)

1인당 PV vs. 로딩속도 High End

High Mid

Low Mid

Low End

High Mid: Dual core 2.4G 급 Low Mid: Pentium 4 3G 급

Source : Performance Related Changes and their User Impact (Eric Schurman, Principal Development Lead, Bing; Jake Brutlag Decision Support Engineering Analyst, Google)

실험: 고의적인 서버 딜레이 주입

- 1.0%

- 0.8%

- 0.6%

- 0.4%

- 0.2%

0%

0.2%

3주 4주 5주 6주 7주 8주 9주 10주 11주

대조군

대비 1

인당

검색량

저하율

서버 딜레이 주입 딜레이 제거 후에도 회복 안됨

-0.36%

-0.74%

-0.08%

-0.21%

: 0.2s

: 0.4s

Source : Performance Related Changes and their User Impact (Eric Schurman, Principal Development Lead, Bing; Jake Brutlag Decision Support Engineering Analyst, Google)

1인당 QC 1인당 재검색 수

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%

1초 딜레이 = 매출 ⇩ 3%

왜 그럴까?

나쁜 사용자경험

만족도 저하

재방문 기피

PV 하락

매출 저하

당연한 거 아님?

님 바보? ㅋㅋ

나쁜 사용자경험 만족도 저하 재방문 기피 PV 하락 매출 저하

로딩 = 수천만 사용자가 멍때리는 낭비하는 시간

로딩 검색결과

열람 검색 로딩

랜딩페이지 열람

로딩 검색결과

열람 검색 로딩

페이지 열람

로딩

검색결과 열람

검색 로딩

페이지 열람

로딩

로딩

로딩 검색결과

열람 검색 로딩

페이지 열람

로딩

검색결과 열람

검색 로딩

페이지 열람

로딩

추가 PV

로딩

로딩

로딩

추가 PV

1. 로딩시간을 줄이면

전체 사용자의 총 가처분 시간이 늘어난다

2. 가처분 시간이 늘어나면 결국

사용자와 웹 생태계 모두의 이득

∴ 단 0.1초라도 빠를수록 좋다!

0.1초는 체감하기 힘든 짧은 시간, 하지만……

Navigation Timing API

window.performance.timing

지원: IE 9+, FF7+, Chrome 6+

Web Performance WG: http://www.w3.org/2010/webperf/

Web Performance WG: http://www.w3.org/2010/webperf/

로딩시작 onunload() onclick()

로딩끝 onload()

장점

가장 정확한 현실

전체 PV 샘플링

실제 사용자의 매 PV별 속도 집계

단점

출시 사후에만 측정 가능

상세 원인분석 불가

구현체

nav timing API, boomerang.js

$$$: torbit.com, CorrelSense, Google Analytics…

DIY: piwik.org, stathat.com, StatD, Graphite…

IDC 또는 가정집에 설치한 agent에서 측정

변수통제: 네트워크/PC 배경부하, 캐시

상세분석: TTFB, Waterfall, 시각성능(RST, AFT)

모니터링

구현체

$$$: Gomez, Keynote

DIY: WebPageTest

인위적으로 구성된 네트워크 + Agent로 랩 테스트

인위적으로 구성된 네트워크 + Agent로 랩 테스트

과연 내 서비스 사용자 환경과 같을까?

대표성이 있을까?

Synthetic Measurement tool

네이버 사용자 환경 재현 테스트

Calibrated test network & agent

Desktop and mobile support

Waterfall, filmstrip, regression

Track F / 16:30~17:10 http://me2.do/50rkntO

http://me2.do/line

웹 개발자 입장에서 보면…

DataCenter

단순 투자로는 개선 불가

노력하면 효율화 가능 NW, HW, OS, Browser

사용자 콘텐츠 마크업 UI코드

공급자 콘텐츠 디자인

서버 성능

Peak 대비 200% 이상의 headroom 용량 확보

장애에 대응하기 위한 이중화 및 overprovisioning

DataCenter

사용자 환경

NW, HW, OS, Browser

사용자 콘텐츠

가입자당 최대속도: 평균 50Mbps, 그러나…

“The State of the Internet”, 2012Q1, Akamai

“The State of the Internet”, 2012Q1, Akamai

4Mbps 이하 가입자가 14%

53% 33%

14%

한국 가입자 속도분포

>10Mb

4~10Mb

<4Mb

대역폭이 5M 있어도 2.5M 밖에 쓰지 못함

http://www.belshe.com/2010/05/24/more-bandwidth-doesnt-matter-much/

실제로 웹브라우저가 쓰는

유효대역폭은 RTT에 반비례

왜 다 쓰지를 못하니?

TCP handshake

TCP slowstart

Browser blocking

웹/앱 개발자 입장에서 궁금한

모바일 네트워크의 속사정

3G 네트워크의 latency 문제

TCP/HTTP 성능저하의 이유

RRC state transition

Track C / 15:40~16:20

http://me2.do/FzTGenF

28%

43%

21%

8%

CPU 등급 분포

High end

High mid

Low mid

Low end

0.0

1.0

2.0

3.0

4.0

5.0

6.0

High

End

High

Mid

Low

Mid

Low

End

네이버 전체 평균 (초)

저사양 사용자 30%, 2.5배까지 느려짐

High mid: dualcore 2.4GHz 급 Low mid: P4 3GHz 급

47%

29%

11%

8%

4% 1%

브라우저별 PV 점유율

IE8

IE9

IE7

chrome

IE6

기타

0.0

0.5

1.0

1.5

2.0

2.5

3.0

3.5

4.0

IE 9 IE 8 IE 7 IE 6

네이버 전체 평균(초)

IE6,7 PV 비중은 15%, 1.7배 느려짐

노력하면 효율화 가능

마크업 UI코드

공급자 콘텐츠 디자인

서버 성능

0.73

0.65 0.63 0.59

0.42

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

총용량 이미지용량 총 건수 이미지 건수 js 용량

로딩시간과의 상관관계 (Correlation)

2012/9, http://httparchive.org

※ 사용자 환경과 콘텐츠가 크게 다르기 때문에 로딩속도 상대비교는 배제

2012/9 랭키닷컴 상위 100 사이트

http://httparchive.org

3.2

1.1 1

0.6

0

0.5

1

1.5

2

2.5

3

3.5

웹페이지 총 용량 (MB)

국내T100

국내포털

해외전체

해외T100

0

100

200

300

400

0 500 1,000 1,500 2,000 2,500 3,000 3,500

총 1.5MB 이하, 리소스 200개 이하, 웹 폰트 사용배제

Request (단위: 개)

Size (단위: KB)

(4.9s)

(2.8s)

(5.1s)

(1.8s)

(3.5s)

(3.3s)

(1.7s)

(3.0s)

(3.1s) (3.8s)

(4.1s)

(1.5s)

(1.7s)

(2.4s) (3.5s)

3s~

2~3s

~2s

네이버 서비스별 리소스 현황

1. 갑, 기획자, 디자이너, 개발자의 의기투합

Speed = PV = $$$

“사용자에게 꼭 필요한 것만 넣자”

2. 실사용자 속도 측정

RUM 또는 calibrated test

개발자 PC는 일반적으로 실사용자 PC보다 훨씬 빠르므로 *주의*

3. 웹 최적화에 시간 할애하기

프로젝트, 유지보수 공수에 산입

기초적인 WPO 적용

4. Goto 1.

Steve Souders “바이블”

쉽다

얇다

한글판도 있다

자동 진단 도구

Yslow, Pagespeed

자동 최적화 도구

mod_pagespeed

미사용 이미지, 중복 이미지

미사용 css, js 코드

웹폰트 – 2MB나 되므로 효율성 제고

주석문, 공백, 너무 긴 변수명

“Minify” built in build machine

gzip 압축 전송 적용

압축-해제 비용보다 이득이 훨씬 많음

불필요한 정보 제거

btn_moviepage_left_on.gif btn_prev2.gif

미사용 css 이미지 중복 이미지

크기에 맞게 서버에서 리사이즈한 후 내려주기

<img width=xxx height=yyy> 태그 리사이즈 금지

이미지 최적화

불필요한 메타정보 삭제 (Exif, embedded thumbnail)

적절한 포맷(PNG/GIF/JPG) 및 압축률 선택

Tools: Image optimizer, Smush.it, Kraken, …

이미지 용량 낭비 = 네트워크 비용 낭비

여러 이미지를 한 개의 sprite로 병합

공수가 많이 들지만 매우 효과적

http://spriteme.org/

CSS Sprite

Expires, Cache-control: max-age 헤더

생략하면 불필요한 conditional GET(304) 요청 유발

Last-modified 헤더

생략하면 GET If-Modified-Since 대신 무조건 GET(200) 요청

Etag 헤더

동일 URL에 대해 서로 다른 Etag가 붙어오지 않는지 확인

권장 사항

Etag 미사용, Last-Modified + Expires 필수

CSS는 렌더링에 필수적이므로 html 가장 위에 배치

JS는 브라우저를 block 시키므로 가급적 아래쪽에 배치

CSS는 위로, JS는 아래로

Js 로딩 파싱

blocking으로 인한 이미지 로딩 지연

http://me2.do/line

Nspeed 데모

웹 페이지 최적화

네트워크 성능

브라우저 성능

Off-the-record 수다떨기

2층 소회의실18:30-19:30