성능 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

 

New Multi-Channel Dynamic CMS

성능 TEST를 위한 보고서 2


1. JMeter

Apache JMeter는 웹 애플리케이션처럼 클라이언트-서버 구조로 된 소프트웨어의 성능 테스트를 위해 만들어진 자바 프로그램입니다. Apache Tomcat의 테스트를 위한 코드에서 시작되어 GUI와 기능을 추가하여 지금의 JMeter가 만들어졌습니다. 원래는 웹 응용 프로그램을 테스트하기 위해 설계되었지만, 현재는 단위/성능/스트레스 테스트 등 많은 곳에서 활용할 수 있습니다. 프로토콜도 계속 추가되어 TCP, HTTP(S), FTP, JDBC, LDAP, SMTP 등 현재 범용으로 사용되는 프로토콜 대부분을 지원합니다.

 JMeter는 실행 시 마치 브라우저(또는 여러 개의 브라우저)에서 동작하는 것처럼 느껴집니다. 그러나 JMeter는 브라우저가 지원하는 모든 작업을 수행하지 않습니다. HTML 페이지에 있는 javascript를 실행하지 않고 HTML 페이지를 브라우저처럼 렌더링하지도 않습니다. 이로 인해 JMeter 툴을 이용한 성능테스트 시 응답 시간은 실제 응답 시간과 조금 차이가 날 수 있습니다.

 

2. JMeter 설치

다운로드 : http://jmeter.apache.org/download_jmeter.cgi (최신버전 다운로드)

                https://archive.apache.org/dist/jmeter/binaries/ (이전버전 다운로드)

윈도우에 설치를 원하시면 zip 파일을 받아 압축을 풀어 사용하시면 됩니다. JMeter를 실행하기 위해서는 Java 6 이상이 설치되어 있어야 합니다. (최신 버전 4.0의 경우는 Java 8 이상)

저는 현재 개발 환경이 Java 7로 설치되어 있으므로, apache-jmeter-2.13.zip을 다운로드하여 사용하였습니다.

압축을 풀고 bin 폴더 안에 있는 jmeter.bat 파일을 실행시키면 오른쪽과 같은 JMeter GUI가 실행됩니다.

JMeter는 부하 발생을 목적으로 하는 프로그램이어서 외부 웹 서버에 접속해서 테스트하면 외부 서버에 부하가 발생하거나 내부 네트워크 트래픽에 과부하를 줄 수 있으므로 사용 방법을 익히는 단계에서는 자신의 로컬에 테스트 타깃 서버를 만들어 놓고 테스트를 진행하는 것이 좋습니다.

 

3. JMeter 사용 방법

JMeter에서는 테스트 스크립트를 “Test Plan”이라고 표현합니다. 웹 서버를 테스트하기 위한 간단한 Test Plan을 만들어 보겠습니다.

- Test Plan 작성 순서

 가. Thread Group 추가 및 설정 : 가상 사용자(Thread)의 숫자와 반복 횟수, 반복 시간을 설정합니다.

 “Test Plan > add > Threads(Users) > Thread Group” 추가

Number of Threads(users) Thread 생성 개수를 의미합니다.
Ramp-up Period(in seconds) 전체 Thread가 전부 실행되는 시간을 의미합니다. 예를 들어, Thread의 개수가 5개이고 Ramp-up Period가 15초 일 경우, 첫 번째 Thread가 수행된 후 다음 Thread가 수행될 때가지 3초를 대기한다는 의미입니다.
Loop Count 각 Thread가 몇 번씩 실행할 것인지를 의미합니다. Forever를 체크 시 개수 상관없이 무한대로 실행됩니다.

위와 같은 Thread Group 설정은 10명이 10번씩 Test Plan을 반복하라는 의미로 총 100회 Test Plan을 수행합니다.

 

- Test Plan 작성 순서

 나. Config Element(HTTP Request Defaults) 추가 및 설정 : 실제 Thread가 어떤 동작을 하는지 설정합니다.

 “Thread Group > add > Config Element > HTTP Request Defaults” 추가

Server Name or IP 성능테스트를 수행할 도메인 명 또는 IP 입력합니다. (전체 URL을 입력하지 않습니다.)
Port Number 포트를 입력합니다.
Path 호출할 전체 URL에서 IP 또는 도메인 명과 Port를 제외한 나머지 URL을 입력합니다.
Send Parameters With the Request 호출한 URL에 전달할 Parameter를 설정합니다.

 

- Test Plan 작성 순서

 다. HTTP Request Sampler 추가 및 설정

 “Thread Group > add > Sampler > HTTP Request” 추가 (테스트 페이지의 개수 만큼 추가)

Path 호출할 전체 URL에서 IP 또는 도메인 명과 Port를 제외한 나머지 URL을 입력합니다.
Send Parameters With the Request 호출한 URL에 전달할 Parameter를 설정합니다.

 

- Test Plan 작성 순서

라. Listener 추가 및 설정 : Sampler의 요청에 대한 결과를 수집해서 그 결과 값을 보여주는 Element입니다. 요청을 보낸 후 성공/실패, 응답시간, 응답 메시지 등을 확인하기 위해 반드시 추가되어야 합니다.

 “Thread Group > add > Listener > View Result Tree”

 “Thread Group > add > Listener > Summary Report”

Test Plan이 모두 작성되었으므로 성능 테스트를 실행시켜보도록 하겠습니다.

제가 설정한 Test Plan은 10개의 Thread가 10번씩 수행되며 한번 수행 될 때

localhost:8080/main/main.jsp, localhost:8080/mk/main/main.jsp, localhost:8080/ml/main/main.jsp

세 도메인이 호출되므로 각 도메인당 100번의 호출. 총 300번의 테스트가 이루어집니다.

 

4. JMeter 테스트 결과 확인

가. View Result Tree

각 결과의 요청/응답을 상세하게 살펴볼 수 있는 Listener입니다.

Sampler result 해당 Sampler의 요청 결과를 보여줍니다. 성공/실패 여부를 포함해 응답시간과 크기 등을 보여줍니다.
Request 해당 Sampler가 웹 서버에 보낸 Request 정보를 볼 수 있습니다.
Response data 해당 Sampler의 요청에 대한 응답 메시지를 보여줍니다. 웹 서버로 요청을 보냈으므로 Response data는 html 문서로 출력됩니다.

 

. Summary Report

테스트 결과를 요약해서 보여줍니다. 통합된 요청량, 응답시간, 오류율, 단위 시간당 처리량 등을 확인할 수 있습니다.

 

5. JMeter 플러그인 추가

JMeter는 성능 테스트 IDE 답게 플러그인을 추가할 수 있습니다.

JMeter 플러그인은 https://jmeter-plugins.org 에서 다운로드할 수 있습니다. 저는 Response Times Over Time 이라는 테스트 결과를 차트로 제공하는 플러그인을 다운로드하여 활용해 보겠습니다. 아래 그림과 같이 플러그인을 다운로드합니다.

 

다운로드를 하고 압축을 풀면 아래 화면처럼 lib폴더가 있고 내부에 ext 폴더와 jar이 있습니다. 이 폴더와 파일을 JMeter가 설치된 폴더에 경로에 맞게 각각 넣어주시면 됩니다. 그 후 JMeter를 재실행하면 Listener에 새롭게 추가된 것을 확인할 수 있습니다.

 

시간에 따른 각 도메인별 응답 시간과 트랜잭션 처리량을 차트로 제공합니다.

 

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

성능 TEST를 위한 보고서 1

 

 

New Multi-Channel Dynamic CMS

성능 TEST를 위한 보고서 1

1. 성능 TEST ?

서비스 및 서비스 시스템의   성능을 확인하기 위해 실사용 환경과 비슷한 환경에서 테스트를 진행하는 것입니다.

 

2. 성능 TEST의 종류

성능테스트는 목적에 따라 다음과 같이 나뉩니다.

Load 테스트  시스템의 성능을 벤치마크 하기 위한 테스트를 의미합니다. 이 테스트는 부하(Load)를 순차적으로 증가시키면서 응답시간이 급격히 증가하거나 더는 처리량이 증가하지 않거나 시스템의 CPU와 Memory 등이 기준 값 이상으로 증가하는 등 비정상 상태가 발생하는 임계점을 찾아 이를 바탕으로 성능 이슈에 대한 튜닝과 테스트를 반복합니다.
Stress 테스트 임계값 이상의 요청이나 비정상적인 요청을 보내 비정상적인 상황의 처리 상태를 확인하고 시스템의 최고 성능 한계를 측정하기 위한 테스트를 의미합니다.
Spike 테스트 갑자기 사용자가 몰렸을 때 요청이 정상적으로 처리되는지 그리고 그 업무 부하(Workload)가 줄어들 때 정상적으로 반응하는지를 확인하기 위한 테스트를 의미합니다.

Stability 테스트 / Soak 테스트

긴 시간 동안 테스트를 진행해서 테스트 시간에 따른 시스템의 메모리 증가, 성능 정보의 변화 등을 확인하는 테스트를 의미합니다. 짧게는 한 두 시간부터 길게는 며칠 동안 진행합니다.

 

3. 성능 TEST 용어

트랜잭션(Transaction)

일정한 단위를 나타내며, 주로 업무/기능별로 트랜잭션을 정의합니다. 웹 어플리케이션에서는 주로 화면 조작을 통한 요청(Request)과 그에 대한 응답(Response) 화면을 하나의 트랜잭션으로 정의하여 사용합니다.

TPS(Transaction Per Second)

1초에 처리할 수 있는 트랜잭션의 수를 나타내며, 성능테스트의 가장 중요한 지표로 사용됩니다. 예를 들면, 성능테스트 결과 30TPS가 나오면 1초에 30개의 트랜잭션을 처리할 수 있다는 의미입니다.

응답시간(Response Time)

사용자가 요청을 보낸 시점부터 처리 결과가 사용자 PC의 화면에 보여질 때까지의 시간을 의미합니다. 웹 어플리케이션의 경우는 Network Time + Server Time + Client Time의 총합을 나타냅니다. 최근 들어 정보 기술의 발달로 인해 더욱 빠른 응답시간이 요구되므로 사용자 측면에서 뿐만 아니라 서비스 공급자 입장에서도 매우 중요한 지표입니다.

 

4. 성능 TEST 목적

성능테스트는 일반적으로 시스템 개발 종료시점에 수행하며, 응답시간과 처리량, 병목구간 등을 실제 서비스 전에 확인하여 서비스나 서비스 시스템의 문제점을 개선하는데 주로 목적을 가집니다.

 

5. 성능 TEST 기대효과

(1) 시스템 측면 : 주요 성능 결함 및 구조적 위험 우선 식별, 운영시스템 성능 최적화, 유지보수 비용  및 시스템 비용 최소화 등

(2) 사용자 측면 : 서비스의 품질 개선, 응답시간 향상을 통한 업무 효율 증대, 사용자 만족도 향상 등

 

6. 성능 TEST의 필요성

(1)  4초 Rule : 4초 이내에 응답이 오지 않으면 다른 사이트로 이동하는 습성

    -  0.5초 : 웹사이트의 첫 화면이 0.5초 안에 방문자의 눈길을 끌지 못하면 고객을 놓침  

       (2006년 지트린 가드 박사, ‘행동과 정보과학‘ 발표 논문 중)

   - 1초 : 1초 지연으로 1%의 매출 감소(아마존)

   - 3초 : 소비자가 웹사이트에 첫 인상을 갖는 시간

   - 4초 : 온라인 구매자들이 최대한 견딜 수 있는 평균 로딩시간(고객 이탈 시간)

(2)  웹 사이트의 장애로 인한 파급효과

     - 70%의 기업이미지 손상

     - 50% 매출 손실

     - 35% 장애 복구 비용

     - 22% 고객 상실

(3) 웹/인터넷을 이용하는 고객의 약 46%가 가장 즐겨찾는 Site의 문제로 인해 다른 Site로 옮긴 경험이 있으며,

      사용자의 92%가 Site 선택의 가장 중요한 요소는 안정적인 시스템. 즉 신뢰성이라고 응답 위와 같은 통계들을 통해 

      웹 성능테스트는 선택이 아닌 필수라는 것을 확인할 수 있습니다.

 

다음 시간에는 성능 TEST 에 주로 이용되는 OPEN Source 에 대해 알아 보도록 하겠습니다.

 


성능 TEST에 대한 더 자세한 내용을 살펴보고 싶다면, 아래 링크를 클릭해주세요.

▶ 성능 TEST를 위한 보고서 2

▶ 성능 TEST를 위한 보고서 3


 

 

 

New Multi-Channel Dynamic CMS