TPS(Transaction Per Second)

메시지 지향 미들웨어(Message Oriented Middleware: MOM)과 그를 구현하는 메세지큐 시스템에 대해 공부하다가 TPS라는 단어를 마주했다. 개발자라면 알아야 할 기본적인 단어 같은데, 들어보기만 했지 제대로 알아본적이 없어서 공부해보려 한다.

 

TPS(Transaction Per Second)

 

Transaction Per Second란 뜻 그대로 초당 실행된 트랜잭션의 개수를 뜻하는데, 이는 그대로 시스템의 성능 측정 지표가 된다. 실제 계산하는 방식은 일정 기간동안 실행된 트랜잭션의 개수를 구하고 다시 1초 구간에 대한 값으로 변경한다. 예를 들어 와탭의 경우 5초 구간으로 값을 수집하기 때문에 단위시간 동안 집계된 트랜잭션의 수를 5로 나눈 값이 표시된다.

 

TPS 계산하기

 

위의 그림에서 두번째 행을 보면 5개의 트랜잭션이 실행완료된 것을 볼 수 있는데, 이 경우 TPS를 구하는 방법은 5 transaction / 5 sec 이므로 결과값은 1 TPS 가 된다. 이처럼 구간 내의 트랜잭션 수 (transaction) /  수집 구간 초 (sec)로 계산할 수 있다.

 

Saturation Point와 TPS

Saturation Point : 요청이 증가해도 TPS가 특정 값으로 수렴하는 것

 

서비스 시간이 일정하기 때문에 초반에는 요청이 증가할수록 어느 수준까지는 처리량이 선형적으로 증가한다. 이후 서비스에 사용자가 지속적으로 늘어나면 어느 순간부터 TPS가 더이상 증가하지 않는 상황이 발생하는데, 이 지점을 Saturation Point 라고 하고 이 때의 동시 사용자 수를 최대 허용 동시 사용자라고 표현한다.

 

위의 그림은 서비스의 이상적인 상황이고, 제대로 튜닝이 되지 않은 서비스는 Saturation Point를 지나면 오히려 TPS가 떨어지기도 한다. (TPS가 수렴하고 떨어지지 않아야 정상적이며, 떨어진다면 개선해야 한다!)

 

위 그림의 서비스는 사용자가 300명이 넘어가면 TPS가 고정되면서 상대적으로 트랜잭션의 응답시간이 길어질 것을 예상할 수 있다.

→ 위의 서비스에서 동시 접속 사용자가 300명이 넘어가면 TPS는 더이상 올라가지 않아 서비스의 정체 시간이 증가한다.

→ 만약 300명의 요청 사항에 대한 TPS가 50이라면 해당 요청사항을 다 처리하는데 약 6초가 소요된다고 예상할 수 있다.

 

이처럼 TPS와 동시접속자를 미리 선정해봄으로써 서비스의 성능을 예상하여 측정할 수 있다.

성능 테스트의 한 형태인 Critical Performance Test (임계 성능 테스트)의 경우, Saturation point를 찾아내는 것을 목표로 한다.

이를 통해 해당 시스템의 한계 성능을 확인하여 최대 TPS와 그 때의 응답시간과 자원 사용률, 최대 허용 동시 사용자 등을 알 수 있다!

 

TPS에 대해 알아보았는데, 아직 신입 개발자인 나로서는 서비스의 성능을 측정한다라는 부분까지는 생각해보지 않았는데 앞으로 팀 프로젝트나 개인 프로젝트를 할 때에도 동시 접속자 수를 늘려서 내가 개발한 서비스의 성능을 측정해보면 좋은 경험이 되지 않을까 하는 생각이 들었다.