AJAX.Widgets: Performance

레이블이 Performance인 게시물을 표시합니다. 모든 게시물 표시

IE 플러그-인 : 성능(속도) 분석 툴 IE Watch

브라우저 기반의 웹 기반 시스템은 간단한 설치와 업그레이드, 그리고 손쉬운 유저인터페이스로 인해 사용자에게 좋은 이미지를 획득하지만 간혹 발생하는 늦은 응답 속도의 문제로 인해 사용자의 짜증을 유발하는 경우가 있다. 이러한 늦은 응답 속도 및 성능 저하 원인을 분석하는 방법에는 LoadRunner, 제니퍼 등의 툴을 이용하여 성능 테스트와 분석을 수행하는 방법이 대표적이다. 그러나 이 방법은 성능 테스트 및 분석을 위한 비용이 만만치 않기 때문에 사전 테스트를 위해 아파치 그룹의 JMeter 등의 오픈 소스 진영의 부하 테스트 툴을 많이 사용하기도 한다.

여기서는 서버 부하 성능 테스트 툴이 아닌 웹 브라우저 기반에서 간단히 성능(속도)을 테스트할 수 있는 툴인 IE Watch을 소개하고자 한다.

IE Watch > HTTP Monitoring

1컬럼: Http Item 단위, 요청-응답 순서 필드
2컬럼: Offset, 요청시작 시간
3컬럼: Position, 수행 시간 위치
4컬럼: Duration, 요청 후 수행된 시간
5컬럼: Size, HTTP Unit Size
6컬럼: Method, GET/POST
7컬럼: Status, Http Response Code
8컬럼: Type, Http Type
9컬럼: URL, Http Request URL

이 툴은 위 그림과 같이 HTTP Monitoring을 지원한다. HTTP Capture를 통해 요청과 응답을 단위로 클라이언트 입장에서 얼마나 해당 요청들이 속도가 어느정도인지 간략히 파악할 수 있다.
위 그림에서 빨간 색으로 되어 있는 부분을 보면 Http Item 단위와 단위사이에서 1초 시간 정도의 Gap이 있는 것을 확인할 수 있다. 이는 51번 요청과 52번 요청 사이에 로직적으로 문제가 있다는 의미이다.
이러한 Http Monitoring 과정을 통해 문제가 있는 프로그램을 간단히 확인할 수 있을 뿐 아니라, 각 요청이 수행된 시간을 확인함으로써 속도 저하의 원인을 추적할 수 있다.

IE Watch > Quick Access Page

Capture된 HTTP를 통해 해당 페이지의 소스를 간단히 볼 수 있다.

IE Watch > Quick Access Script, Image, CSS, Form in a Page

Capture된 HTTP를 통해 해당 페이지의 리소스별, 즉 Script, CSS, Image, Form 데이터 등을 간단히 볼 수 있다.

IE Watch > Request & Response Header View

Capture된 HTTP Unit 별로 Request 및 Response Header의 상세 내용을 확인할 수 있다.

이 글은 2008-05-07 에 작성된 글 입니다.

웹 어플리케이션 성능 - 테스트의 객관적 관점

앞에서 성능에 대한 객관적 사실들을 도출하기 위해서 필요한 요소들과 사용되는 도구에 대해서 언급했다. 이 장에서는 성능테스트를 위한 객관적 관점에 대해서 정의하고 이를 바탕으로 웹 어플리케이션 성능 테스트 범위와 대상을 도출할 예정이다.

성능(Performace) 테스트의 객관적 관점은?

성능이라는 것은 앞에서 이미 정의했지만, 단위 시간당 특정 시스템이 처리할 수 있는 최대 처리 가능한 건수를 말한다. 이를 전문용어로 TPS(Transaction Per Seconds)라 하였다.

웹 기반 시스템에서 성능(Performance)을 도출할 때 많은 사람들이 응답속도에 집착하는 경향이 있다. 물론 응답속도가 빠르면 단위시간당 처리하는 건수가 높아지는 상관관계가 있지만, 평균응답시간과 더불어 동시(Active Clients)에 몇 개가 수행되느냐에 따라 단위시간당 최대 처리건수가 달라지는 추가적인 상관관계를 놓치면 안된다.

예를 들어, 한 명의 유저가 특정 어플리케이션을 1분 동안 반복적으로 수행하여 그 응답시간을 측정하여 평균응답시간을 구하는 것은 의미가 별로 없다는 것이다. 반면 여러 명의 유저가 특정 어플리케이션 또는 여러 개의 어플리케이션을 1분 동안 반복적으로 수행하여 동시에 동일한 테스트를 수행하고 그 응답시간을 측정하여 평균응답시간을 구해보면 당연히 한 명이 수행할 때보다 그 성능은 느려질 것이다. 이러한 관점에서 동시 테스터(Active Client)들을 5명,10명,20명 등으로 요청하는 사람들을 늘려가면 어떤 특정한 인원까지 평균응답시간이 점차 증가하다가 더 이상 증가하지 못하는 수치에 머무르게 될 것이다. 이 시점에서 발생할 수 있는 것은 서버 성능상 부하로 인하여 큐잉(Queuing) 현상이 발생하는 최고치가 될 수 도 있고, 특정 어플리케이션의 문제로 발생할 수 도 있고 등등이 문제의 원인들이 될 것이며, 이것이 바로 의미가 있는 성능 테스트인 것이다.

Active Client?

Active Clients라는 개념은 테스트를 시행할 개별적인 테스터(Tester)의 개수를 의미하는 것으로 일부 제품에서는 이를 동시사용자(Concurrent Users)라는 용어로 표기되기도 하며, “# of Run Thread”라는 용어로 불리기도 한다. (이후부터는 용어의 통일을 위해 Active Clients 함)
또한 Active Clients 개념하에서 스트레스 테스트를 수행할 때 가장 중요한 기본적 조건은 개별적 Acitve Clients는 반드시 앞서 보낸 응답이 온 뒤에야 그 다음 요청을 날릴 수 있다는 것이며, 거의 모든 스트레스 툴에서는 이 요건들을 만족한다.

아래 그래프는 Active Clients 증가에 따른 전형적인 단위시간당 처리건수와 평균응답시간의 그래프이다.

위 그래프는 Active Clients가 57까지는 일정한 수치에 머물다가 70개가 넘어서는 순간부터 지속적으로 선형적인(linear) 증가를 보이고 있다. 이는 동시에 최대 Active Clients가 70을 기점으로 하여 TPS가 더이상 증가하지 않고 또한 그에 따라 평균응답시간도 증가되는 현상이 발생하는 것이다. 즉 서버측에서 70 Active Clients까지는 큐잉(Queuing) 현상이 발생하지 않고 적정한 성능을 보인다고 할 수 있으며, 평균응답시간 역시 고정된 수치가 아니라, Active Clients 증가에 따라 변화하는 특징을 가진다고 볼 수 있다. 그에 따라 "Active clients 70 일 때 평균응답시간 xx초" 와 같은 표현은 가능할 지라도, "그 응용 어플리케이션의 성능은 평균응답시간이 xx초이다"라는 표현은 잘못된 것이라 결론을 내릴 수 있다.

따라서, 웹 기반 시스템에서 성능(Performance)측정의 기준이 되는 수치는 단위시간당 최대처리건수를 의미하는 최대 TPS(Transaction Per Second)가 가장 적절한 정의가 된다.

어떤 시스템을 개발하고 그에 대한 성능을 구하고자 할 때 접근방식을 바꾸어야 한다. 즉, 단일 요청에 대해 그 응답시간이 탁월하다고 하여 시스템 성능이 아주 좋다고 판단 해서는 안되며 또한 단일 요청에 대해 그 응답시간이 느리다하여 성능이 좋지 않다고 결론을 내려서는 안된다. 최대 TPS가 높다는 것은 단위시간당 더 많은 건수의 처리를 할 수 있다는 것을 의미하며, 단위시간당 호출건수는 통상 동시사용자의 증가에 비례하여 많아지기 때문이다. 결국 최대 TPS가 높다는 것은 보다 많은 동시사용자를 수용할 수 있다는 것을 의미한다.

[참고자료]
메가트랜드 자바 2002, 웹 기반 시스템하에서의 성능에 관한 이론적 고찰
Performance Analysisfor Web-based Enterprise System, Lee WonYoung, 2002
제 4 회 한국 자바 개발자 컨퍼런스 2003, JVM/WAS 기반 자바 어플리케이션의 튜닝 및 성능 관리
한국소프트웨어 컴포넌트 표준화 포럼 2002, J2EE 시스템의 성능 향상 방안

이 글은 2008-04-15 에 작성된 글 입니다.

웹 어플리케이션 성능 - 테스트 도구

웹 성능 분석에 관한 이론 및 접근방법론은 경험 지식의 축적이 미비하여 아직 제대로된 객관적 자료가 나와 있지 않은 듯 하다. 그러다 보니 웹 시스템 성능분석 및 벤치마크 테스트는 경험적 지식에 의하여 시행되는 경우가 많다. 이러한 현상들은 웹 기반 시스템의 역사가 짧다 보니 그 성능을 어떻게 측정해야 하는지? 무엇이 성능이며, 그 특성은 어떻게 정의할지? 또한 동시 사용자는 무엇이고 어떻게 측정해야 할지? 스트레스트 테스트는 어떻게 수행되어야 하며 그 분석 방법은 무엇인지 등 그 이론적 지식이 부족한 것으로 나타난다.

성능(Performace) 테스트 대표적 도구들은?

웹 성능과 관련된 이론과 접근방법의 현실적 문제는 일단 인정한다고 하더라도 보다 나은 객관적 사실들을 발견하고 성능을 판단하기 위해서는 성능 측정을 위한 도구들이 필요하다. 이러한 대표적 도구(Tool)은 다음과 같다.

Mercury사의 LoadRunner (http://www.merc-int.com)
Rational Suite Performance Studio (http://www.rational.com)
라메르정보기술㈜의 e-Test Suite (http://www.lamer.co.kr)
Microsoft 사의 Web Application Test Tool (http://webtool.rte.microsoft.com)
Apache 그룹의 JMeter(http://apache-korea.org)

서로 다른 종류의 다양한 스트레스 테스트툴이 존재하지만, 모든 제품들은 최소한 다음과 같은 2가지 항목을 측정하도록 해 주고 있다.

Active Clients에 따른 평균응답시간(Mean Response Time)
Active Clients에 다른 단위시간당 처리건수(TPS:Transaction Per Second)

위에서 열거한 여러가지 성능테스트 도구 중 일반적으로 가장 많이 사용하는 것은 Mercury사의 LoadRunner이다. 모든 제품이 그러듯이 테스트를 위해 사용되는 모든 기능들을 사용하기에는 라이센스 문제가 걸림돌이 된다. 라이센스가 문제라면 오픈 소스 진영인 Apache 그룹의 JMeter를 사용하는 것도 하나의 방법이다.

웹 어플리케이션 성능 - 개요

브라우저 기반의 웹 기반 시스템은 간단한 설치와 업그레이드, 그리고 손쉬운 유저인터페이스로 인해 사용자에게 좋은 이미지를 획득하지만 간혹 발생하는 늦은 응답 속도의 문제로 인해 사용자의 짜증을 유발하는 경우가 있다. 이러한 늦은 응답 속도의 원인을 사용하고 있는 통신망 전송능력의 한계와 트래픽 과다등 환경적 요소도 있으나, 근본적인 원인은 웹 사용자의 증가에 따른 예측 대비능력과 이를 수행할 시스템 성능, 그 능력을 제대로 평가하지 못하고 사용자 오픈을 한 것에 있다.

성능(Performace) 판단 기준은?

예를 들어 JSP/Servlet 환경하에 두 개의 웹 기반 어플리케이션이 다음과 같이 존재한다고 가정하고

A인 경우 - 단위 응답시간 1초
B인 경우 - 단위 응답시간 5초

브라우저에서 몇 번의 단위테스트를 통해 A-시스템인 경우 평균 응답 시간이 1초이고, B-시스템인 경우는 평균 응답 시간이 5초가 걸렸다면 상대적으로 빠른 A-시스템이 B-시스템보다 성능이 우수하다고 판단할 것이다. 그러나 단순한 평균 응답 시간만 갖고 시스템의 성능을 평가하는 것이 올바른 관점이라 볼 수 없다. 즉, "성능(Performance)라는 것은 단위 요구당 평균 응답 시간을 가지고 시스템의 Performance을 논하지 말아야 한다"는 것이다.

성능(Performace) 판단 고려사항

Performance라는 것은 단위 시간당 특정 시스템이 처리할 수 있는 최대 처리 가능한 건수를 말한다. 이를 전문용어로 TPS(Transaction Per Seconds)라 한다. TPS는 단위 시간당 응답속도인 Average Response Time(평균응답시간)이 높으면 당연히 TPS도 높아질 것이다. 하지만 이러한 TPS을 높이는 상관 관계가 있는 요소들을 면밀히 검토해야 한다.

Active Clients
Web에서 Transaction의 의미
Saturation Point(임계점)
Light Load Zone
Heavy Load Zone
Buckle Zone
Concurrent User