혼자 컴퓨터에서 쓰는 프로그램, 즉 워드나 파워포인트같은 1인용 프로그램의 성능을 판단하는 기준은?
응답시간(Response time)이다.
개인 사용자 관점에서 얼마나 반응이 빠른가가 가장 중요하고 이는 중요한 몇개의 기능에 대한 응답시간의 평균으로 그 성능을 판단할 수 있다.
그렇다면 웹 애플리케이션같은 다수의 사용자가 HTTP 요청을 통해 폼데이타와 HTML메시지를 주고받는 경우의 성능을 판단하는 기준은?
여러 요인이 있을 수 있지만 가장 의미있는 기준은 최대 TPS(Transaction Per Second)이다.
개인 사용자 관점에서야 응답시간이 중요할 수 있지만 웹 애플리케이션처럼 다수가 사용하는 경우 동시 접속자수가 증가하면 응답시간은 지속적으로 증가하기 때문에 응답시간의 절대적인 수치를 측정할 수가 없다. 반면에 TPS는 해당 웹 애플리케이션이 처리가능한 최대의 트랜잭션 양이므로 메시지 크기가 크게 다르지 않다는 가정에서는 일정 수준 이상 증가하다가 최대 수치를 기록한 이후 더이상 증가하지 않는다. 따라서 이 최대 TPS를 가지고 해당 웹애플리케이션의 성능을 상대적으로 비교하는 것이 가능하다.
이 TPS는 지금까지도 웹 애플리케이션의 성능을 평가하는 데 가장 중요한 요소로서 많은 벤치마크테스트에서 활용되고 있다. 그러나 최근 이 TPS만 가지고는 변화해가는 웹 환경에서 절대적인 기준으로 활용하기에 적합하지 않은 시나리오가 종종 발생하고 있으며 이는 조금씩 증가하고 있다는 느낌이다.
상황의 발단은 UCC나 Web 2.0시대로 접어들면서 과거보다 훨씬 큰 크기의 데이타가 한 트랜잭션에서 전송되는 테스트시나리오 및 고객 상황이 발생하고 있는 것이다.
즉 트랜잭션마다의 특성이 너무나 천차만별이기에 동일한 웹 애플리케이션으로 성능을 테스트하더라도 애플리케이션 특성상 다양한 크기의 데이타를 가지고 테스트해야만 하는 상황이 많이 발생하였다. 특히나 웹과 같은 오픈환경에서 멀티미디어 데이타 전송을 처리하려는 TELCO회사들에서 진행하는 벤치마크 테스트에서 자주 접해볼 수 있었다. 더욱이 클라우드 컴퓨팅의 시대에 접어들면서 더 많은 컴퓨팅 파워를 클라우드에 일임하고 그럼으로써 대용량의 트랜잭션 처리가 날이 갈수록 절실하게 요구되고 있다.
아래 그림에서 보면 WebApp1의 TPS는 4, WebApp2의 TPS는 1이다. 어떤 고객은 요청 크기가 커졌다고는 하지만 어떻게 TPS가 4이던게 1로 뚝 떨어질 수 있는가, 성능이 너무 떨어지는 것이 아니냐고 하지만 결과적으로 보면 두 상황은 동일한 성능의 다른 수치일 뿐 성능을 제대로 표현하고 있는 기준으로 이야기하고 있는 것이 아니다.
그래서 나는 최근에 경우에 따라서는 고객에게 TPS만이 성능을 판단하는 절대기준이 아니며 때로는 BPS (Bytes Per Second)가 더 유효한 성능 기준임을 강조하고 있다.
응답시간(Response time)이다.
개인 사용자 관점에서 얼마나 반응이 빠른가가 가장 중요하고 이는 중요한 몇개의 기능에 대한 응답시간의 평균으로 그 성능을 판단할 수 있다.
그렇다면 웹 애플리케이션같은 다수의 사용자가 HTTP 요청을 통해 폼데이타와 HTML메시지를 주고받는 경우의 성능을 판단하는 기준은?
여러 요인이 있을 수 있지만 가장 의미있는 기준은 최대 TPS(Transaction Per Second)이다.
개인 사용자 관점에서야 응답시간이 중요할 수 있지만 웹 애플리케이션처럼 다수가 사용하는 경우 동시 접속자수가 증가하면 응답시간은 지속적으로 증가하기 때문에 응답시간의 절대적인 수치를 측정할 수가 없다. 반면에 TPS는 해당 웹 애플리케이션이 처리가능한 최대의 트랜잭션 양이므로 메시지 크기가 크게 다르지 않다는 가정에서는 일정 수준 이상 증가하다가 최대 수치를 기록한 이후 더이상 증가하지 않는다. 따라서 이 최대 TPS를 가지고 해당 웹애플리케이션의 성능을 상대적으로 비교하는 것이 가능하다.
이 TPS는 지금까지도 웹 애플리케이션의 성능을 평가하는 데 가장 중요한 요소로서 많은 벤치마크테스트에서 활용되고 있다. 그러나 최근 이 TPS만 가지고는 변화해가는 웹 환경에서 절대적인 기준으로 활용하기에 적합하지 않은 시나리오가 종종 발생하고 있으며 이는 조금씩 증가하고 있다는 느낌이다.
상황의 발단은 UCC나 Web 2.0시대로 접어들면서 과거보다 훨씬 큰 크기의 데이타가 한 트랜잭션에서 전송되는 테스트시나리오 및 고객 상황이 발생하고 있는 것이다.
즉 트랜잭션마다의 특성이 너무나 천차만별이기에 동일한 웹 애플리케이션으로 성능을 테스트하더라도 애플리케이션 특성상 다양한 크기의 데이타를 가지고 테스트해야만 하는 상황이 많이 발생하였다. 특히나 웹과 같은 오픈환경에서 멀티미디어 데이타 전송을 처리하려는 TELCO회사들에서 진행하는 벤치마크 테스트에서 자주 접해볼 수 있었다. 더욱이 클라우드 컴퓨팅의 시대에 접어들면서 더 많은 컴퓨팅 파워를 클라우드에 일임하고 그럼으로써 대용량의 트랜잭션 처리가 날이 갈수록 절실하게 요구되고 있다.
아래 그림에서 보면 WebApp1의 TPS는 4, WebApp2의 TPS는 1이다. 어떤 고객은 요청 크기가 커졌다고는 하지만 어떻게 TPS가 4이던게 1로 뚝 떨어질 수 있는가, 성능이 너무 떨어지는 것이 아니냐고 하지만 결과적으로 보면 두 상황은 동일한 성능의 다른 수치일 뿐 성능을 제대로 표현하고 있는 기준으로 이야기하고 있는 것이 아니다.
그래서 나는 최근에 경우에 따라서는 고객에게 TPS만이 성능을 판단하는 절대기준이 아니며 때로는 BPS (Bytes Per Second)가 더 유효한 성능 기준임을 강조하고 있다.
공유하기 버튼
|
|
덧글