Async 멀티쓰레드 환경에서의 jMeter 사용팁(RPS vs TPS)

현재 개발하는 Application 은 해외 사업자와 인터페이스 해야 되는 환경이다....

데이터가 내부에 없으므로 거의 모든 데이터를 해외 서비스 사업자의 인터넷 회선에 의존해야 한다. 

네트워크 지연시간을 최소화 하기 위해서 여러개의 요청을 멀티쓰레드로 동시 호출하여 사용자에게 응답 주기전에 정리/통합하여 보여준다. 

사용자에게 응답줄때도 전체 요청에 대한 응답을 기다렸다가 리턴하지 않고 사용자가 지루해 하지 않게(?) 중간중간 응답값을 정리해서 리턴하고 최종적으로 모든 응답값을 정리해서 다시 리턴하는 구조를 가졌다.

성능에 대한 이슈가 많이 발생할 수 밖에 없는 구조이기 때문에 부하테스트는 필수적인 요건이다.....하지만 여기서 jMeter를 사용하는데 대한 여러가지 문제가 발생한다. 여기서 가장 큰 문제는 Async 의 구조적인 문제다.

일반적인 Application 에서 사용자가 A 페이지를 요청하면 시스템은 A페이지를 처리해서 사용자에게 요청한다. 이때 사용자가 요청하고 응답받을때까지 걸린 시간이 10초이면 시스템은 10초동안 1개의 Transaction을 처리한다. (0.1TPS)

만일 시스템이 서로다른 사용자에 대해서 최대 10명의 요청을 동시에 처리할 수 있다면 10명의 요청을 동시에 10초동안 처리하게 되고 이때 시스템은 1TPS(Transaction Per Second)의 용량을 가진게 된다.

하지만 Async 의 구조에서 사용자는 A 페이지를 요청하지만 시스템은 A페이지 처리이후 별도로 B,C,D 세개의 Transaction 을 처리한다. 결국 사용자입장에서 A, B, C, D 네개의 Transaction 이 모두다 끝나야지만 원하는 응답을 모두 받게 되는 것이다.

jMeter로 Async 환경을 테스트 하는 경우 jMeter 는 A페이지의 부하만 생성해서 시스템에 부하를 주기 때문에 A 페이지를 초당 10번 호출하는 경우 시스템은 A,B,C,D 네개의 Transaction을 수행하고 의도와는 다르게 시스템은 20개의 Transaction을 수행하게 된다.

따라서 A 페이지의 호출을 우리가 원하는 시간당 횟수로 호출하여야만 시스템의 부하를 테스트 추정할 수 있게 된다.

예를 들어 A페이지를 초당 10번 호출하면 시스템은 A,B,C,D 총합 40개의 호출을 하게되고 이 때 시스템의 평균응답값이 10초이면 시스템은 4TPS의 용량을 가지고 있다고 말할 수 있게 된다.

이렇게 특정 호출(jMeter에서는 Thread)를 정해진 빈도로 호출하기 위해서는 Thread Group 에 Constant Throughput Timer를 추가해야 한다. A페이지를 일정한 Throughput 으로 호출하여 시스템에 init 페이지에 대한 RPS(Request Per Second)를 조절해야만 전체적인 부하량을 조절할 수 있게 된다. 

2018.02.28 추가

또한 이 경우 기존 TPS 가 사용자의 요청을 처리할 수 있는 사용자입장의 처리량과 서버의 처리용량 모두를 표현할 수 있었다면 Async 환경하에서의 TPS는 사용자에게 초기 응답값을 전달할 수 있는 TPS와 전체 응답값을 전달할 수 있는 응답값에 대한 TPS 가 다르기 때문에 사용자 입장에서의 TPS(즉, RPS)와 서버 인프라 측면에서의 TPS가 각각 다른 수치를 모이게 되기 때문에 지표설계에 주의해야 한다.