메뉴 건너뛰기


Developer > Development Tools

기타 Grinder 사용기

2013.11.25 16:57

푸우 조회 수:14217

이번에는 오픈 소스 진영의 로드(스트레스) 테스트 툴인 Grinder를 활용하는 방법에 대해서 알아보도록 하겠습니다.
 
사실은 스트레스 테스트를 할 일이 있는데...
오랜만에 하니깐 하는 방법이 잘 기억이 안나고 해서 기왕 다시 하는 거 이번에는 강좌를 작성하면서 해야 겠다고 생각했습니다.
 
자 그럼 시작해 보죠.
 
1. Grinder의 설치
 
Grinder의 홈페이지는 http://grinder.sourceforge.net이구요.
http://sourceforge.net/projects/grinder 에서 다운로드 받으실 수 있구요.
위의 사이트가 좀 느리더군요.
 
zip파일을 다운 받으신 다음 압축을 푸세요.
그리고 적당한 디렉토리에 놓습니다.
저는 C:\JAVA\Grinder3.0 폴더에 저장했습니다.
아 참... Grinder를 돌릴려면 JAVA version 1.4 이상이 필요합니다.
 
 
2. 동작 방식의 이해
 
Grinder는 다목적 로드 테스트 프로그램입니다. 그래서 좀 복잡합니다.
먼저 용어부터 알아보도록 하겠습니다.
 
1) Worker processes
Worker는 말 그대로 일을 하는 프로세스를 이야기 합니다.
Worker는 Jython 스크립트로 동작방법을 명시하게됩니다.
어찌되었건 Worker는 Web Server에 실제 요청을 보내고 받는 것과 같은 동작을 합니다.
 
2) Agent processes
Agent는 테스트할 컴퓨터의 각 Woker들을 관리합니다.
즉, Agent가 실제로 Worker를 동작시키게 됩니다.
Agent의 설정을 properties파일을 통해 하게됩니다.
또한 Agent는 다음의 console과 통신하여 동작 명령을 받거나 결과를 console로 통보하게 됩니다.
 
3) The console
Agent에게 시작 및 종료명령을 보내고 Agent로 부터 온 결과들을 취합해서 통계를 내거나 리포트를 만들게 됩니다.
 
 
3. 동작 환경 꾸미기
 
동작을 편리하게 할 수 있도록 몇가지 작업을 하도록 하겠습니다.
작업디렉토리를 하나 정하세요.
예로 C:\test 라는 폴더를 정했다면 C:\JAVA\Grinder3.0\examples 폴더의 "grinder.properties"파일과  "http.py"파일을 복사해 놓습니다.
 
그리고 C:\test 폴더에 다음과 같은 파일을 만드세요.
 
setGrinderEnv.cmd
set GRINDERPATH=C:\JAVA\Grinder3.0 set GRINDERPROPERTIES=C:\Test\grinder.properties set CLASSPATH=%GRINDERPATH%\lib\grinder.jar;%CLASSPATH% set JAVA_HOME=C:\JAVA\j2sdk1.4.2_11 PATH=%JAVA_HOME%\bin;%PATH%
 
위에서 JAVA_HOME은 여러분의 JAVA가 설치된 폴더를 지정해야 합니다.
 
startAgent.cmd
call C:\Test\setGrinderEnv.cmd echo %CLASSPATH% java -cp %CLASSPATH% net.grinder.Grinder %GRINDERPROPERTIES%
 
startConsole.cmd 
call C:\Test\setGrinderEnv.cmd java -cp %CLASSPATH% net.grinder.Console
 
startProxy.cmd 
call C:\Test\setGrinderEnv.cmd java -cp %CLASSPATH% net.grinder.TCPProxy -console -http > grinder.py
 
이번에는 Web Stress 테스트를 위해 grinder.properties 파일을 열어서  
 
"grinder.script=helloworld.py" 의 제일 앞에 #을 입력하여 주석처리하시고.
그 다음 라인의 "#grinder.script=http.py" 부분의 #을 제거하여 주세요.
 
그런 다음 http.py 파일을 열어서 17라인 쯤에 있는
"result = request1.GET("http://localhost:7001/")" 부분의 URL을 테스트 하길 원하는 URL로 수정하세요.
 
자 이제 간단한 Web Stress 테스트를 위한 설정이 모두 끝났습니다.
 
4. Stress Test하기
 
이제 실제 Stress Test를 해 보도록 하겠습니다.
먼저 Grinder Console을 띄워야 합니다.
Command 창을 하나열어서 C:\Test로 이동하세요.
그런 다음 "startConsole"을 입력합니다.
그럼 아래와 같은 화면이 나타나게 됩니다.
이게 바로 Grinder의 Console입니다.
20071115_050855.png
 
지금은 아무 Agent도 Console에 접속하지 않았기 때문에 아무 동작도 할 수 없습니다.
 
자 이번에는 또 다른 Command창을 띄우고 다시 C:\Test 폴더로 가서 "startAgent"라고 입력합니다.
 
20071115_051210.png
 
Agent는 GUI가 아닙니다. 단지 명령차에 위와 같이 Console의 신호를 기다린다는 메시지만 표시되게 됩니다.
 
Console의 입장에서 보면 Agent가 접속해서 이제 뭔가를 할 수 있는 상태가 된거죠.
그래서 다음과 같은 툴바가 활성화 됩니다.
20071115_051400.png
 
또한 Console에서 다음과 같이 Agent가 접속했다는 것을 알 수 있습니다.
20071115_051529.png
 
 자 그럼 이제 동작시켜보도록 하죠.
 
20071115_051400.png
 
위의 툴바 중 제일 첫번째 툴바를 클릭합니다.
이 툴바는 "Start the Worker Processes"라는 이름을 갖고 있습니다. 즉, Agent에 명령을 보내 Worker를 실행하겠다는 것이죠.
20071115_051901.png
 
아무튼 클릭하면 위와 같은 메시지 박스가 나타납니다.
script를 설정하지 않아 worker들은 agent의 properties에 의해 동작 될 것이라고 합니다. 그냥 "확인" 합니다.
 
정상적으로 설정하였다면 다음과 같은 화면이 나타납니다.
20071115_052601.png  

 
C:\Test 폴더에 보면 log 라는 디렉토리가 생겨 있을 겁니다.
여기서 *.html 파일이 하나 있습니다. 이게 worker가 작업을 해서 가져온 파일입니다.
 
자 대충 흐름은 알았죠?
 
윈도우즈의 작업관리자를 열어보세요. 특별한 java 응용프로그램을 띄우지 않았다면 Grinder Console과 Agent를 띄운 java.exe가 하나씩 두개 떠 있을 겁니다.
 
이상태에서 다시 툴바의 "Start the Worker Processes" 버튼을 클릭하면 java.exe가 하나 더 떴다가 내려가는 걸 확인 할 수 있을 거예요.
이건 "grinder.properties"파일에 grinder.processes=1 로 설정되었기 때문입니다.
이값을 바꿔 보도록 하죠.
 
20071115_054510.png
 
Console에서 script 탭을 열어 grinder.properties를 엽니다.
grinder.processes의 값을 5로 바꿔보죠. 그런다음20071115_054841.png  버튼을 눌러 저장하고  20071115_054655.png  버튼을 클릭해서 Agent에 이 값을 다시 읽도록 합니다.
그런 다음  "Start the Worker Processes" 버튼을 누르고 작업관리자를 보세요.
그러면 java.exe가 5개 떴다가 내려가는 것을 볼 수 있습니다.
Web Server입장에서 보면 5개의 브라우져가 결과를 요청한 꼴이 되는 거겠죠.
이번에는 grinder.threads값을 10로 만들어 보세요.
즉, 5개의 브라우져가 동시에 10개씩 결과를 요청하는 꼴이 됩니다. 웹서버는 거의 동시에 50개의 요청을 받게 되는 거겠죠?
이번에는 grinder.runs의 값을 5로 바꿈니다. 이것은 5개의 브라우져가 각각 10번씩 요청을 하는데 이것을 연속 5번 하겠다는 것입니다. 이제 웹서버는 총 250번의 요청을 받았을 것입니다.
이런식으로 프로세스 수, 쓰레드 수(동시요청), 반복 수 등을 조절하며 테스트 하면 됩니다.
 
하지만 테스트를 수행하는 컴퓨터도 리소스의 한계가 있기 때문에 너무 많은 수의 프로세스나 쓰레드는 대상 웹 사이트의 성능과는 별개로 테스트 컴퓨터의 한계로 결과가 제대로 나오지 않을 수도 있습니다.
이런 경우는 Agent를 한 컴퓨터가 아닌 여러 컴퓨터에 분산시켜서 동작시키고 Grinder Console로 제어해 가며 테스트 할 수도 있습니다.
 
또한 한 컴퓨터에서도 Agent를 여러개 만들 수도 있으며 각각의 Agent마다 다른 웹페이지를 요청하게 할 수도 있습니다.
 
 5. 결과 보기
 
위와 같이 여러 값들을 바꿔가며 테스트를 했다고 해도 테스트한 결과를 봐야 어디다가라도 써먹을 수 있겠죠?
20071115_060330.png
 
위의 캡쳐된 그림을 보면 다음과 같은 결과를 알수 있습니다.
Test에 성공한 건(Succesful Tests) 250건
에러(Errors)는 0건이네요.
평균 시간(Mean Time)은 2020 밀리초(즉, 2초 정도되네요)
평균 시간 표준 편차(Mean Time Standard Deviation)는 1560 밀리초,
TPS(trasaction per second)는 0.0980
최고 TPS(Peak TPS)는 37.0번
평균 응답 길이(Mean Response Length)는 25700바이트
초당 응답 바이트(Response Bytes Per Second)는 2520바이트
응답 에러(Response Errors)는 0
(Mean time to resolve host)는 14.2
연결하기 위한 평균 시간(Mean time to establish connection)은 15.8
첫번째 바이트를 받을 때 까지으니 평균 시간(Mean time to first byte)은 26.0
 
으로 나오네요.
우수하네요.
 
 
 
Creative Commons License
Creative Commons License이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
Copyright 조희창(Nicholas Jo). Some rights reserved. http://bbs.nicklib.com