ngrinder로 성능 테스트

Ngrinder 설치

Controller 설치

ngrinder는 네이버에서 만든 오픈소스임으로 github에서 wget을 통해 다운로드 받습니다.

우선 자바를 설치 후 해당 war파일을 실행합니다.

ngrinder를 실행하면 기본 포트인 8080으로 접속하시면 됩니다. ID, PW는 admin으로 기본 설정되어있으며, 보안 상 PW는 변경합니다.

실행 시 github을 확인해보면 MaxPermSize를 설정해줍니다. MaxPermSize는 java 8부터는 사용하지 않습니다. 사용하지 않는 이유는 해당 포스팅에서 벗어나는 내용 같아 참고링크로 대신하겠습니다.

해서 MaxPermSize를 설정하지 않고 바로 실행하였습니다.

java -jar ngrinder-controller-3.5.5-p1.war -p 8080

agent 설치
설치된 controller에 접속하여 agent를 다운로드합니다.

마찬가지로 wget을 통해 agent를 설치 한 뒤 agent.conf파일에서 controller_host, controller_port를 확인 합니다. controller_port는 기본 포트인 16001을 사용합니다.

테스트
실제 careerly 사이트에 트래픽을 주어 정상적으로 동작하는지 확인합니다.

방대한 트래픽을 주어 실제 careerly의 성능을 확인해보고 싶지만 이건 엄청난 민폐가 될 수 있기 때문에 약간의 트래픽만 주어 테스트를 해보았습니다. 😅

Ngrinder 구조

nGrinder는 Controller, Agent, Target 서버로 구성되어있습니다.

Controller : 테스팅을 위한 인터페이스를 제공하는 서버
Agent : Controller가 명령을 받아 실제 부하를 발생시키는 서버
Target : 부하테스트의 대상이 될 서버

nGrinder-Monitor가 설치되면 현재 서버의 상태를 Controller에서 모니터링이 가능합니다.

보통 다수의 agent들과 controller가 통신을 하기 때문에 16001 포트와 12001~120XX를 열어두어야 합니다. xx는 agent 수와 동일하게 설정하시면 됩니다.
두 포트는 Agent가 Controller에게 전달할때 사용하며 각각의 의미는 아래와 같습니다.
16001 : 테스트를 진행하지 않는 agent가 controller에게 쉬고 있다고 알려주는 포트
120xx : 테스트 실행, 종료를 agent에게 controller가 전달하며, agent별 테스트 통계를 수집하는 포트

Agent : Controller의 명령을 받아 실제 부하를 발생시키는 서버
Vuser : 가상 유저로 Vuser = Agent x Process x Thread 갯수입니다.

수행 방법은 Duration, Run Count 둘 중 한개로 설정할 수 있습니다.

Duration은 일정 시간동안 테스트를 진행하는 것이며, Run Count는 말 그대로 지정 갯수만큼 동작하는 것 입니다.
Ramp-up은 특정 구간별로 트래픽을 몰리게 설정하는 것을 말합니다. (x축: 시간흐름, y축: 동시접속자)

해당 테스트에서는 프로세스 증가는 단일코어 당 최대 10개가 한계임으로 스레드를 증가시켜 부하를 발생시키도록 하였습니다.

Scale out을 통한 성능 확인

우선 careers 애플리케이션이 1개일때 상황입니다.

서버를 1개 돌릴 경우 TPS를 보면 754개 정도 처리할 시 CPU가 87%를 차지하는 것을 확인할 수 있습니다.

서버를 2개로 확장 시 Nginx의 Load Balance기능으로 트래픽이 나뉘어 들어가는 것을 확인 할 수 있습니다. 또한 TPS도 1160개로 약 400개 증가한 것을 확인할 수 있었습니다.

그렇다면 이번엔 Ramp up을 사용하여 구간별로 트래픽을 달리주었을 경우 어떻게 동작하는지 확인해보도록 하겠습니다.

뭔가 이상하지 않나요? 🤔제가 처음 생각했을 때에는 시간이 흐를수록 스레드의 갯수가 증가하여 동시접속하는 Vuser가 증가함에따라 TPS도 테스트가 종료될 때까지 계속 상승할 것으로 생각했습니다. 그런데 일정 시간이 지나면 TPS가 급격하게 떨어지는 것을 확인할 수 있었습니다.

Detail report를 통해 좀 더 살펴보도록 하겠습니다.

예상대로 시간이 흐를수록 Vuser의 수는 증가하는 것을 확인할 수 있었습니다. 그렇다면 왜 2분15초에서의 TPS가 급격히 떨어진 걸까요??

설명에 들어가기 전에 몇 가지 용어를 짚어보고 가겠습니다.
성능테스트를 할때 가장 눈여겨 보아야 할 것은 TPS와 Latency입니다.
TPS(Transaction Per Second)는 초당 처리할 수 있는 트랜잭션의 수를 나타냅니다. 보통 하나의 요청에 대한 처리를 트랜잭션 단위로 처리하기 때문에 50 TPS 이면 50개의 기능을 1초에 처리했다라고 생각하면 됩니다.
Latency는 지연시간입니다. 서버에 요청을 보내고 응답을 수신할 때까지의 시간을 말합니다.

자! 그럼 갑자기 TPS가 떨어진 이유는 무엇일까요?

제가 내린 결론은 Latency였습니다. Ngrinder에서는 Mean Test Time(평균 테스트 시간)을 Latency라고 합니다. 위 사진을 보면 2분 15초 부터는 Latency가 서서히 증가하는 것을 확인할 수 있습니다.
즉 동시접속 인원이 증가함에 따라 요청에 대한 지연시간이 증가하게 되고, 이로 인해 서버의 처리량도 감소하게 되어버린 것 입니다.

다음 포스팅에는 지연시간이 어느부분에서 증가하는지 유추해보고 성능 개선 포인트를 알아보도록 하겠습니다.

Reference

https://github.com/naver/ngrinder/wiki/Architecture
https://github.com/naver/ngrinder/wiki/Controller-Configuration-Guide
https://ko.myservername.com/performance-testing-vs-load-testing-vs-stress-testing