nGrinder -> Gatling 테스트 프레임워크 변경기 (with 호스트의 한계..)

요약

• nGrinder의 controller가 nGrinder의 agent가 보내는 요청을 견디지 못하고 죽었다
• 그렇기에 nGrinder로는 breaking point test를 수행하지 못하였다
• nGrinder가 아닌 gatling으로 테스팅 툴 변경해야 한다.

---

nGrinder를 통해 테스트 결과를 얻었습니다. 그리고 이를 정리하다 다음과 같은 에러 로그를 발견하였습니다.

메모리가 부족해 agent가 죽었다고 나옵니다.

 

톰캣 서버가 버티지 못하고 죽은 것이 아닌 톰캣 서버에 요청을 보내는 agent가 부하를 견디지 못하고 죽어버려 테스트가 끝나버린 것입니다. 이를 저는 하나의 agent가 너무 많은 부하를 줬기 때문이라 생각하고 agent의 수를 늘려 다시 테스트를 수행하기로 하였습니다.

(기존에는 하나의 agent로 테스트를 진행하였습니다.)

 

CPU 사용량이 급격하게 올라가는 문제점을 발견할 수 있었습니다.

에이전트 컨테이너를 두개로 늘린후 다시 테스트를 진행하였습니다. 이후 저는 ngrok을 통해 요청이 올바르게 오고 가는지를 확인하고 있었습니다 그러다 아래 cpu 사용량(호스트 == 제 맥북)이 100%찍는 것을 확인하였고 똑같이 테스트가 중단되었습니다.

이후 nGrinder를 도커로 띄웠기에 해당 컨테이너의 로그를 확인해보았습니다.

agent가 찍고 있는 로그들

 

controller가 죽었네..?

 

그 결과 nGrinder 콘솔에서 나오는 agent가 OOM때문에 죽었다는 말과는 다르게 다음과 같이 agent는 에러 로그를 찍고 있었으며 다음과 같이 controller가 죽었다는 로그를 확인할 수 있었습니다.

 

 

컨테이너의 상태들을 확인해본 결과 agent는 살았으나 controller가 죽어 있는 것을 발견할 수 있었습니다…

 

 

짧게나마 nGrinder의 아키텍쳐에 대해 공부한 저의 생각으로 는 agent가 보내는 요청에 대한 결과를 record하는 중에 controller에 부담이 많이 갔는것 같습니다. 그리고 이에 대해 해결책을 생각해보았습니다.

1. 직접 요청을 보내도록 구현한다.
   1. 장점: 요청을 보내는 코드는 금방 작성할 수 있다.
   2. 단점: 요청에 대한 결과를 처리하는 로직을 따로 작성해야 한다.
2. 다른 테스팅 툴을 사용한다. (gatling)
   1. 장점:다른 테스팅 툴인 Jmeter와 다르게 scala기반 테스팅 툴이기에 scala가 지니는 장점을 그대로 얻을 수 있다.(병렬처리, 자바와의 호환, 바이트 코드 최적화로 적은 리소스 사용)
   2. 단점: scala의 학습 곡선이 높다

저는 scala를 사용하는 gatling을 사용하더라도 기본으로 제공되는 예제코드를 살짝 고치는 수준으로 테스트 스크립트를 작성할 것이기에 scala의 높은 학습 곡선은 크게 문제가 되지 않으리라 예상됩니다. 그렇기에 저는 테스팅 툴만을 gatling으로 변경해 다시 테스트를 시도해보려 합니다.

 

참고

nGrinder 테스크 스크립트

https://spidyweb.tistory.com/488

 

깃헙

https://github.com/sami355-24/login_performance_nGrinder