성능 TEST를 위한 보고서 3

1. nGrinder

nGrinder는 The Grinder라는 오픈소스를 기반으로 네이버에서 개발한 성능 측정 오픈소스 프로젝트입니다. Jython(Java + Python) 언어를 이용하여 테스트 스크립트 코드를 직접 작성할 수 있어 JMeter에 비해 다소 무겁지만 세밀한 성능테스트를 진행할 수 있습니다. 또한 jython뿐만 아니라 groovy, groovy+maven을 지원하며, Controller는 WAS기반으로 동작합니다.

 

2. nGrinder Architecture

nGrinder는 Controller, Agent, Target으로 나뉘어 있습니다.

 

Controller	성능테스트를 위해 웹 인터페이스를 제공하며, 테스트 프로세스를 조정할 수 있습니다. 또한, 테스트 결과를 수집하여 통계로 나타내는 역할도 합니다.
Agent	Controller의 명령을 받아 실행합니다. 테스트 스크립트를 수행하는 Worker 개념으로 Target이 되는 머신에 프로세스와 스레드를 실행시켜 부하를 발생시키는 역할을 합니다.
Target	테스트 대상이 될 서버입니다.

 

3. nGrinder 설치

nGrinder는 자바 기반이기 때문에 Controller와 Agent를 설치하려면, Oracle JDK 1.6이상 또는 open JDK 1.7이상, Tomcat 6 버전 이상이 사전 설치되어야 합니다.

다운로드 : http://sourceforge.net/projects/ngrinder/files

(다운로드 된 war 파일은 반드시 스페이스가 포함되지 않는 폴더에 설치하셔야 합니다.)

 

4. nGrinder Controller 설치

nGrinder는 Jenkins와 유사하게 자체적으로 실행 가능한 웹 아카이브 파일(WAR)로 배포됩니다. 따라서 WAR 파일을 직접 자바로 실행할 수도 있고, Tomcat 같은 웹 어플리케이션 서버에 올려 실행할 수도 있습니다.

저는 Tomcat 서버에 올려 성능테스트를 진행하도록 하겠습니다.

가. 다운로드 받은 WAR 파일을 Tomcat의 webapps 폴더(${TOMCAT_HOME}/webapps)에 저장합니다.

가-1. 만약 nGrinder를 컨텍스트 경로(http://localhost/ngrinder-controller-3.3와 같이)가 없이 바로 http://localhost와 같은 형태로 접근하고자 한다면 WAR 파일명을 ROOT.war로 변경하시면 됩니다.

나. nGrinder Controller는 메모리를 많이 사용하기 때문에 메모리 설정이 필요합니다. 아래 설정을 하지 않을 경우, 몇 가지의 관리자 기능이 동작하지 않습니다.

${TOMCAT_HOME}/bin/catalina.sh(리눅스) 또는 ${TOMCAT_HOME}/bin/catalina.sh(윈도우) 파일을 열어 가장 앞 부분에 다음과 같이 메모리 설정을 추가합니다.

다. ${TOMCAT_HOME}/bin/startup.sh(리눅스) 또는 ${TOMCAT_HOME}/bin/startup.bat(윈도우) 파일을 실행합니다.

라. 브라우저를 열고 해당 서버로 접속하면 아래와 같은 로그인 페이지가 나옵니다. (기본 ID/PW는 admin/admin 입니다.)

 

5. nGrinder Agent 설치

가. Tomcat에 설치된 Controller로 로그인을 한 뒤 우측 상단의 메뉴를 클릭하여 “에이전트 다운로드”를 선택해 설치합니다.

나. 설치된 tar 파일을 압축 해제하고, 해제된 폴더로 이동하여 __agent.conf 파일을 확인합니다.   Controller에서 직접 받은 agent 파일의 경우는 ip와 port가 등록되어 있어 수정할 필요가 없습니다. 만약 Controller에서 설정을 바꾸셨다면 agent 설정파일도 수정하여야 합니다.

다. run_agent.sh(리눅스) 또는 run_agent.bat 파일을 실행하여 Agent를 실행시킵니다.

라. Agent 실행 후 Controller에서 우측 상단 메뉴의 “에이전트 관리”를 선택하면 아래와 같이 연결된 Agent 목록을 볼 수 있습니다.

 

6. nGrinder 테스트

가. Quick Start를 이용하여 쉽고 빠르게 테스트를 할 수 있습니다. 테스트 대상 URL을 입력하고 “테스트 시작” 버튼을 클릭하면 사용자의 테스트 스크립트가 자동으로 생성되며 테스트 설정 페이지로 이동합니다.

나. 테스트 방식을 설정합니다.

 

에이전트	Controller와 연결되어 있는 에이전트의 수 만큼 사용가능 합니다.
스크립트	사용자가 해당 주소로 부하를 걸 스크립트를 보여줍니다.
RHEAD	선택된 스크립트의 내용을 보여주는 페이지로 이동합니다.
테스트 대상 서버	테스트를 진행할 서버의 리스트를 보여주며, 추가버튼 클릭 시 테스트 받을 서버를 늘릴 수 있습니다.
테스트 기간	해당 테스트를 얼마만큼 실행할 지 설정하는 항목입니다.
실행 횟수	사용자가 설정한 쓰레드당 몇 번의 테스트를 실행할 것인지를 지정합니다.
Ramp_Up	점차 부하를 가할 수 있는 기능입니다. 부하를 가할 때, 가상 사용자 수를 늘리는 것이 아닌 process나 thread를 늘립니다.
초기 개수	처음 시작 시 가상사용자의 수를 설정합니다.
초기 대기시간	테스트를 언제부터 실행시킬 지를 설정합니다.
증가 단위	해당 process/thread를 몇 개씩 증가시킬지를 설정합니다.
Ramp_Up 주기	설정한 것들의 상승 시간을 설정합니다.

 

6. nGrinder 사용 방법

가. RHEAD 버튼을 클릭하여 생성된 스크립트를 확인/수정 할 수 있습니다.

나. 성능테스트 수행 (수행 중)

성능테스트 수행 중 상단 우측 공 위에 마우스 커서를 올려 놓으면, 팝업 창이 나타나 테스트 진행 메시지를 나타냅니다. 또한, 테스트 진행 현황 탭에서 현재 진행 중인 테스트 상태를 실시간으로 확인할 수 있습니다.

다. 성능테스트 수행 종료 (보고서)

성능테스트가 종료되면 요약된 성능테스트 결과보고서를 보여줍니다. 자세한 결과를 보고 싶으시면 상단에 “상세보고서” 버튼을 클릭하시면 됩니다.

 라. 성능테스트 수행 종료 (상세보고서)

상세보고서 화면에서는 TPS, 평균 테스트 시간, 첫 바이트 평균 도달 시간 등 다양한 정보를 차트로 확인할 수 있습니다.

 

7. JMeter와 nGrinder

7-1 수행결과 비교

동일한 타겟 서버를 대상으로 process/thread 50개씩 20번 반복 총 1000회 호출하여 두 성능 테스트 툴을 비교하였습니다.

두 차트는 시간에 따른 TPS 처리량으로 비슷한 형태의 모양을 나타냅니다. 총 처리 시간은 2:13, 2:12로 거의 동일하며, 최고 TPS, 평균 TPS도 비슷한 값을 가지는 것을 확인할 수 있습니다.

7-2 JMeter 특징

- 최근까지도 꾸준한 Release

- 영문이지만 자세한 매뉴얼과 많은 검색 결과

- 다양한 프로토콜 지원

- 다양한 외부 플러그인을 사용하여 기능 확장 가능

7-3 nGrinder 특징

- 2014년 초 이후 Release 중단

- 국문으로 된 자세한 매뉴얼과 QnA 커뮤니티, 블로그 존재

- 테스트 타켓 서버 모니터링 기능

- 툴이 다소 무거운 감이 있으나, 스크립트 수정으로 세밀한 성능테스트 가능

7-4 결론

두 가지의 성능 테스트 툴을 사용하며 어떤 테스트 툴이 현재 운영중인 서비스의 성능을 테스트 하거나 새롭게 개발할 때 더 유용할지에 대해 고민하였습니다.

현재 운영하는 홈페이지에는 크게 정적 컨텐츠 위주의 페이지와 DB 사용이 많은 페이지로 나뉩니다. 두 성능테스트 툴은 각각 어떤 유형의 페이지에서 효과적일지 확인해봤으나 어떤 유형의 페이지에서든 두 툴은 비슷한 성능테스트 결과를 나타내어 페이지의 유형으로 툴을 선택하기는 어려웠습니다. 그리하여 성능테스트 툴의 결과 외적으로 사용하고 싶은 툴을 선택하였으며 제 선택은 JMeter를 사용하는 것이 더 효과적이며 손쉽게 성능테스트를 할 수 있다고 판단하였습니다.

성능테스트 활용 후 느낀점

성능테스트 툴을 활용해보기 전 성능테스트는 특정 서비스나 사이트의 전체적인 속도를 체크하는 것이라고 생각했습니다.

제 생각과는 다르게 성능 테스트는 서비스 개발 종료시점에 실제 환경과 유사한 상태에서 성능을 테스트하여 발생할 수 있는 문제점을 개선하는 것이었습니다. 이번 기회로 성능 테스트의 필요성을 크게 느껴 추후 새로운 프로젝트나 서비스 개발 종료시점에 성능 테스트를 활용할 예정입니다.

성능 테스트 시 주의해야 할 점은 툴에서 제공하는 그래프나 통계 정보를 맹신하지 않아야 한다는 것입니다. 성능 테스트 툴은 타겟 서버에 부하를 발생시키는 도구 정도로 생각을 하고 타겟 서버의 상태를 직접 모니터링하며, 성능 테스트 툴에서 제공하는 정보를 참고하는 것이 바람직한 성능 테스트라는 생각이 들었습니다.

 

성능 TEST를 위한 보고서 전편의 콘텐츠를 살펴보고 싶다면, 아래를 클릭해주세요.
성능 TEST를 위한 보고서 1
성능 TEST를 위한 보고서 2