Part 1. 웹 페이지 성능분석에 대한 고찰

개요

웹 프로그래머라면 자신이 만든 웹 페이지의 성능에 대해 관심이 많을 것이다. 그래서 보통은 서버단 코드 내에서 웹 페이지 성능에 영향을 줄 수 있는 부분을 찾아 리펙토링하거나 데이터베이스 질의 등을 튜닝하여 성능개선을 한다. 하지만 웹 페이지가 브라우저를 통해 정상적으로 로드되기까지 걸리는 시간 중에서 실제로 서버단 영역의 비중은 그렇게 높지 않다. 사용자가 웹 페이지 자체가 너무 느려서 답답함을 느끼고 있다면 그 원인은 의외로 우리가 평소에 중요하게 생각하지 않았던 부분일 수도 있다. 본 강좌에서는 웹 페이지를 구성하는 요소들에 대한 자세한 내용과 웹 페이지 분석 및 개선 방법에 대해서도 알아볼 것이다.

참고로 필자는 작년부터 올해 초까지 웹 페이지 성능을 주기적으로 분석하고 통계를 내어 공유할 수 있는 솔루션 개발을 진행했었다. 해당 솔루션은 사용자 관점에서 분석하고자 하는 웹 페이지를 직접 브라우저를 통해 접근하여 관련된 데이터를 수집하고, 이를 분석하고 통계내어 서비스 중인 웹 페이지에 대한 정보를 웹 기획 및 개발 쪽에 제공한다.

본 강좌를 쓰게 된 이유는 앞에서 소개한 솔루션 개발을 진행하면서 알게된 사실들과 진행하면서 겪었었던 어려운 점 등을 공유하기 위함이다. 오늘 다룰 내용은 필자의 경험을 바탕으로 작성한 것임을 미리 밝혀둔다.

왜 사용자 관점이어야 하는가?

웹 페이지에 접속을 하면 브라우저는 다양한 유형의 세션(또는 파일)들을 요청하게 된다. 이 세션들은 크게 정적인 것과 동적인 것으로 나눌 수 있다. 정적 세션은 이미지나 자바스크립트, CSS와 같은 것을 말하며 동적 세션은 JSP, ASP, PHP와 같은 서버단 언어로 구현된 세션을 말한다. 그렇다면 이 중에서 어떤 유형의 세션이 웹 페이지에 접속했을 때 로드시간의 비중이 높을까?

그건 바로 정적 세션이다. 물론 서버단 코드가 개판이면 다를 수도 있다. 하지만 우리나라 주요 포털사이트를 기준으로 비교를 해보면 정적 세션의 비중이 월등히 높다. 아래 그래프는 네이버 메인페이지를 구성하는 세션 종류의 비율을 볼 수 있는 그래프이다. 먼저 "Count"는 세션 개수 또는 라운드트립이라고 생각하면 되고, "Time"은 로드시간, "Size"는 다운로드 크기이다. 아래 로드시간 그래프 막대기를 보면 이미지의 로드시간이 절반 이상의 비율을 차지하는 것을 알 수 있다.

위의 그래프에서 서버단 세션은 "_ETC"로 분류가 되어 있는데, 전체 로드시간 중에서 차지하는 비중은 겨우 11.81%이다. 이는 PHP나 Java와 같은 서버단 언어로 구성된 세션들이 웹 페이지의 전체 로드시간에 많은 영향을 주지 않는다는 것이다. (물론 네이버 메인의 경우, 서버단 코드와 데이터베이스 질의 튜닝이 잘 되어있음)

아래 표는 "_ETC"로 세션 유형의 상세 목록이다.

아래는 티켓몬스터의 호스트 유형 비율을 나타내는 막대그래프이다. 자세히보면 알 수 있겠지만 이 사이트는 외부 호스트의 비중이 매우 크다는 것을 알 수 있다. 물론 세션 개수는 티켓몬스터 관련 호스트가 압도적으로 많지만 로드시간은 정반대이다.

만약에 사용자가 티켓몬스터에 방문하였을 때, 웹 페이지가 매우 느리게 느껴진다면 그건 자체적인 문제보단 외부적인 요인이 크다는 것을 알 수 있다. 한가지 예로 필자가 담당하는 웹 사이트가 어느 순간부터 느려진 것 같다는 문의를 받은 적이 있었다. 그래서 원인을 찾아보니 특정 이미지 파일 한개의 로드시간이 매우 느리다는 것을 알 수 있었다. 해당 이미지 파일은 우리 회사의 파일 서버가 아닌 해외 사이트에서 랜덤하게 가져오는 파일이었는데, 아무래도 우리나라가 아닌 해외에 있다보니 커넥션하는데 지연이 되어 전체 로드시간에 영향을 준 것이다. 웹 페이지 성능을 분석할 때에는 이렇게 사용자 관점에서 생각한다면 보다 빨리 문제의 원인을 파악할 수 있다.

웹 페이지 성능분석 기준

정확한 웹 페이지의 성능분석을 하기 위해서는 일반적으로 논-캐시와 캐시, 두가지 형태로 관련 데이터를 측정해야 한다. 다음 강좌인 "웹 페이지 개선방법"에서 자세히 다루겠지만 웹 페이지의 성능을 개선하는데 있어서 가장 큰 효과를 볼 수 있는 것이 캐시 처리이기 때문에 웹 페이지에 처음 방문 했을 때의 상태인 논-캐시와 한번 방문하고 다시 방문하였을 때의 상태인 캐시일 때 모두를 측정해야 정확한 웹 페이지 성능분석이 가능하다.

참고로 아래 표는 한게임의 성능분석 결과이다. 보면 알겠지만 논-캐시와 캐시의 성능 차이가 세션 개수의 경우 8배 정도가 차이나고, 로드시간 또한 5배 정도 차이가 난다. 별도의 튜닝 작업없이 단순히 캐시 처리만 해도 이 정도의 차이가 있기 때문에 웹 페이지 성능분석을 할 때에는 꼭 두 상태 모두 해야만 한다. 그래야만 성능분석의 기준이 명확해지고 특정 문제점을 찾는데 좀 더 수월하게 할 수 있다.

그리고 위의 표를 보면 알겠지만 웹 페이지 성능분석을 하는데 있어서 기준이 되는 지표는 세션 개수(라운드 트립), 로드시간, 다운로드 크기이다. 지표 별로 나타나는 수치들은 조금씩 다른 의미를 가진다. 먼저 절대적인 값을 가지는 지표는 세션 개수(라운드 트립)과 다운로드 크기이다. 여기서 말하는 절대적인 값이란 성능분석을 하는 환경이 무엇이든 동일한 수치가 나온다는 것을 말한다. 하지만 로드시간은 세션 개수와 다운로드 크기와 달리 환경에 따라 평균 값이 변하는 상대적인 값이다.

로드시간이 상대적인 이유에 대해서 설명하기 전에 먼저 로드시간의 구성 요소에 대해 설명하도록 하겠다. 아래는 "Pingdom Tools"로 네이버를 성능분석한 결과 값인데, 세션의 로드시간은 "DNS를 찾는 시간", "서버에 연결하는 시간", "서버로 데이를 보내는 시간", "서버로부터 데이터를 받기 위해 기다리는 시간", "서버로부터 데이터를 받는 시간" 등 다양한 형태의 시간들이 종합되어 있다.

각각의 세션 로드시간의 유형에 대한 비율을 보면 한가지 이상한 점이 있을 것이다. 그건 바로 "DNS를 찾는 시간"과 "서버에 연결하는 시간"이 너무 비율이 높다는 것이다. 그 이유는 바로 "Pingdom Tools"의 성능분석 서버가 국내가 아닌 해외에 있기 때문이다.

참고로 아래는 국내에서 측정한 세션의 유형 별 로드시간이다. "DNS를 찾는 시간"과 "서버에 연결하는 시간"이 "Pingdom Tools"로 측정한 결과와 많은 차이가 있음을 알 수 있을 것이다. (거의 미미한 로드시간)

이렇게 로드시간은 환경적인 요소들에 영향을 많이 받기 때문에 절대적인 값이 측정 될 수가 없다. 즉, 로드시간은 세션 개수와 다운로드 크기와는 달리 상대적인 값인 것이다. 그럼, 아래 그래프를 보자.

위의 그래프는 일 기준으로 1시간 단위로 웹 페이지 성능분석을 한 결과이다. 세션 개수와 다운로드 크기의 그래프는 일정하게 그려졌지만 로드시간은 특정 시간에 급격한 변화가 있는 것을 알 수 있다. 이런 현상이 나타나는 이유는 웹 페이지 서버의 트래픽이 갑자기 증가해서 순간적으로 느려졌거나 클라이언트 환경 상의 문제 등 로드시간에 영향을 끼칠만한 다양한 변수들이 존재하기 때문이다.

그렇기 때문에 아래 네모박스 영역의 평균적인 값들만을 추출하여 분석하는 방법이 필요하다.

만약에 필자가 성능분석에 사용했던 솔루션이 문제가 있을수도 있다라고 생각한다면 "Pindom Tools"나 "Fiddler" 그리고 "HttpWatch"와 같은 툴들로 직접 확인해보면 로드시간이 얼마나 불규칙하게 측정이 되는지 알 수 있을 것이다. 참고로 필자가 우연찮게 국내 유명 벤치마킹 솔루션 업체의 웹 페이지 성능분석 기준을 알게 되었는데, 상당히 이해하기 어려운 분석 기준이었다. 그 업체의 분석 기준의 가장 큰 문제점은 로드시간을 분석하는데 있어서 논-캐시와 캐시 상태를 구분하지 않는다는 것이었다. 앞에서 잠깐 설명을 하였지만 한게임의 경우, 논-캐시와 캐시 상태의 웹 페이지 로드시간은 5배 정도의 차이가 있다고 했다. 만약에 논-캐시와 캐시 상태 구분없이 단순히 로드시간의 평균치를 구한다면 분석된 데이터 값은 일관성을 잃게 된다.

웹 페이지 로드시간은 관련 벤치마킹 툴들을 이용하여 직접 측정해보면 알겠지만 테스트할 때마다 시간 차이가 많이 난다. 예를 들어 첫번째 테스트의 로드시간이 "2.674초"였고, 두번째 로드시간은 "3.251초"라고 가정할 때, 시간 차이는 "0.577초" 밖에 나지 않는 것처럼 보이지만 이것을 백분율로 환산하면 무려 "21.6%"의 차이가 난다.

아래는 "Pingdom Tools"로 네이버를 몇일 동안 로드시간을 측정한 결과 지표이다. 빨간색 네모 영역을 보면 알겠지만 로드시간은 최소 "2.65초", 최대 "6.55초"이다. 무려 "3.9초"가 차이가 나며 이를 백분율로 환산하면 "147.2%"의 차이가 난다. 그리고 앞에서 말한 것처럼 다운로드 크기나 세션 개수는 절대적인 수치이기 때문에 측정을 정상적으로 했다면 각각의 테스트 결과의 편차가 심하지 않다. (10% 내외)

로드시간은 앞서 말한 것처럼 환경에 따라 테스트 결과의 편차가 심하기 때문에 이를 해결할 수 있는 방법이 필요하다. 그래서 필자는 프로젝트를 진행하는 과정에서 편차를 줄일 수 있는 방법을 찾기 위해 고심하였고, 결국 다양한 시도 끝에 해결할 수 있었다.

아래 그래프는 3월 5일부터 3월 18일까지의 웹 페이지 로드시간의 일별 통계 수치이다. 빨간색 네모 영역을 보면 최저와 최고 시간의 편차가 1초를 넘지 않는다. 이렇게 웹 페이지의 성능분석을 자동화하고, 정확한 결과 값을 얻을 수 있다면 앞으로 생산될 다양한 웹 서비스를 적용하는데 있어서 최소한 성능에 관한 문제는 발생하지 않을 것이다.

추가적으로 "Pingdom Tools"는 웹 페이지를 국가 별로 성능분석을 할수 있는 기능을 제공한다. 솔직히 필자는 웹 페이지의 로드시간을 국가 별로 측정하는 것은 그렇게 큰 의미는 없다고 생각한다. 국가는 단순히 로드시간에 영향을 미치는 변수들 중에 하나일 뿐이다.

예를 들어 네이버의 로드시간을 서로 다른 환경의 "A, B, C"에서 측정한다고 가정해보자. 여기서 말하는 서로 다른 환경이란 국가, PC 사양, 인터넷 속도 등등 다양한 변수들이 복합적으로 작용되어 있는 것을 말한다. 또한 "A, B, C"의 측정 결과가 편차가 심하지 않다라고도 가정해보자. 그렇다면 "A, B, C"의 평균 로드시간이 "1초, 2초, 3초"라고 한다면 이 중 어떤 값이 정확하게 측정된 수치일까?

답은 바로 "A, B, C" 모두이다. 그렇기 때문에 웹 페이지의 평균 로드시간을 말할 때에는 측정한 환경에 대하여 자세하게 명시해야 한다.

마무리

이번 강좌는 실무에서 그동안 진행해왔던 프로젝트 경험을 토대로 정리한 것입니다. 그렇기 때문에 내용이 다소 주관적일 수도 있습니다.그리고 웹 페이지 성능개선 방법에 대해서도 이번 장에서 다룰려고 하였으나 분량이 너무 길어져서 부득이하게 다음 강좌로 미루었습니다. 다음 강좌에서는 실무에 적용하여 실제로 효과를 본 웹 페이지 성능개선 방법들에 대해 자세하게 다뤄볼 생각입니다. 물론 소개할 방법들이 그렇게 특별한건 아닙니다. 그냥 정리 차원에서 다루는 것이기 때문에 새로운 것을 기대하신거라면 살짝(?) 실망할 수도 있습니다. 그럼, 다음 강좌도 기대해주세요. ^^

추천 링크

Pingdom Tools, http://tools.pingdom.com/fpt/

Web Wait, http://webwait.com/

Web Page Test, http://www.webpagetest.org/

Site-Perf, http://site-perf.com/

Fiddler, http://www.fiddler2.com/fiddler2/

HttpWatch, http://www.httpwatch.com/