웹 어플리케이션 성능 - 테스트의 객관적 관점
| 웹 어플리케이션 성능 - 테스트의 객관적 관점 |
| 앞에서 성능에 대한 객관적 사실들을 도출하기 위해서 필요한 요소들과 사용되는 도구에 대해서 언급했다. 이 장에서는 성능테스트를 위한 객관적 관점에 대해서 정의하고 이를 바탕으로 웹 어플리케이션 성능 테스트 범위와 대상을 도출할 예정이다. |
성능(Performace) 테스트의 객관적 관점은?
성능이라는 것은 앞에서 이미 정의했지만, 단위 시간당 특정 시스템이 처리할 수 있는 최대 처리 가능한 건수를 말한다. 이를 전문용어로 TPS(Transaction Per Seconds)라 하였다.
웹 기반 시스템에서 성능(Performance)을 도출할 때 많은 사람들이 응답속도에 집착하는 경향이 있다. 물론 응답속도가 빠르면 단위시간당 처리하는 건수가 높아지는 상관관계가 있지만, 평균응답시간과 더불어 동시(Active Clients)에 몇 개가 수행되느냐에 따라 단위시간당 최대 처리건수가 달라지는 추가적인 상관관계를 놓치면 안된다.
예를 들어, 한 명의 유저가 특정 어플리케이션을 1분 동안 반복적으로 수행하여 그 응답시간을 측정하여 평균응답시간을 구하는 것은 의미가 별로 없다는 것이다. 반면 여러 명의 유저가 특정 어플리케이션 또는 여러 개의 어플리케이션을 1분 동안 반복적으로 수행하여 동시에 동일한 테스트를 수행하고 그 응답시간을 측정하여 평균응답시간을 구해보면 당연히 한 명이 수행할 때보다 그 성능은 느려질 것이다. 이러한 관점에서 동시 테스터(Active Client)들을 5명,10명,20명 등으로 요청하는 사람들을 늘려가면 어떤 특정한 인원까지 평균응답시간이 점차 증가하다가 더 이상 증가하지 못하는 수치에 머무르게 될 것이다. 이 시점에서 발생할 수 있는 것은 서버 성능상 부하로 인하여 큐잉(Queuing) 현상이 발생하는 최고치가 될 수 도 있고, 특정 어플리케이션의 문제로 발생할 수 도 있고 등등이 문제의 원인들이 될 것이며, 이것이 바로 의미가 있는 성능 테스트인 것이다.
웹 기반 시스템에서 성능(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가 높다는 것은 보다 많은 동시사용자를 수용할 수 있다는 것을 의미한다.
또한 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 Analysis for Web-based Enterprise System, Lee WonYoung, 2002
제 4 회 한국 자바 개발자 컨퍼런스 2003, JVM/WAS 기반 자바 어플리케이션의 튜닝 및 성능 관리
한국소프트웨어 컴포넌트 표준화 포럼 2002, J2EE 시스템의 성능 향상 방안
이 글은 2008-04-15 에 작성된 글 입니다.
댓글 없음:
댓글 쓰기