Table of Contents
JMeter란 무엇인가?
다음은 JMeter 홈의 JMeter의 소개와 관련된 부분이다.
Apache JMeter is a 100% pure Java desktop application designed to load test functional behavior and measure performance. It was originally designed for testing Web Applications but has since expanded to other test functions.
What can I do with it?
Apache JMeter may be used to test performance both on static and dynamic resources (files, Servlets, Perl scripts, Java Objects, Data Bases and Queries, FTP Servers and more). It can be used to simulate a heavy load on a server, network or object to test its strength or to analyze overall performance under different load types. You can use it to make a graphical analysis of performance or to test your server/script/object behavior under heavy concurrent load.
Apache JMeter 는 테스트 기능과 퍼포먼스를 측정하는 기능을 갖는 100% 순수 자바 데스크탑 애플리케이션입니다. 원래는 웹 애플리케이션의 테스트를 위해서 설계가 되었지만 현재는 다른 기능의 테스트를 위해 확장되고 있습니다.
JMeter 로 무엇을 할 수 있을까요?
Apache JMeter는 정적(static)이거나 동적(dynamic)인 자원 모두(가령, 파일, 서블릿, 펄 스크립트, 자바 객체들, 데이타베이스와 쿼리들, FTP 서버 등등 다른 것들)에 대해 퍼포먼스들을 테스트 해 볼 수 있습니다. 서버나 네트워크 혹은 객체들에 대해서 과도한 부하를 주어 시뮬레이션 테스트도 가능하며 다른 부하 에 대해서도 전반적인 퍼포먼스를 분석할 수 있습니다. 또한 JMeter로써 퍼포먼스에 대한 분석을 그래픽하게 나타낼수 있으며 개발자들의 서버나 스크립트 객체들에 대해 과도한 동시 처리 부하를 테스트할 수 있습니다.
이것만 보았을때 아.. JMeter는 부하를 측정하게 해주는 거구나 라는 것을 알 수 있다.
난 JMeter란 것에 대해서 관심을 가지게 된 것은 한번도 해보지 않은 분야여서다..
최소한 나로서는 개발자로서 개발하다보면 내가 만든 프로그램이 얼마나 부하를 가져올까란 궁금은 하지만 사실 이러한 일에 관여해보기가 힘들었던 게 사실이다.
그래서 한번 관심을 가져보기로 했다.
물론 기준점은 Web application 하의 부하 테스트가 기준이 될 것이다.
JMeter의 설치
JMeter 홈에서 JMeter를 다운 받는다.
JMeter Home 에서
다운 받아서 압축을 불면 다음과 같은 디렉토리로 구성되어 있다.
디렉토리 구조를 살펴보면
/bin 에는 실행관련 파일들이 들어있습니다.
/docs 와 /printable_docs에는 사용자 매뉴얼과 데모가 들어있습니다.
/extras 는 JMeter를 ant로 바로 실행할수 있도록 하는 설명이 들어있고요
/lib에는 JMeter를 실행하면서 로딩해야할 다른 서드 파티 jar파일을 넣으면 됩니다 만약 JDBC 테스팅을 한다면 해당하는 벤더의 JDBC를 넣으면 된다.
/bin 디렉토리에 jmeter.bat 파일을 실행하면 JMeter의 화면을 볼수 있다.
보라 Swing 의 썰렁함을 ..
일단 어떤 툴에 있어서 중요한 점은 항상 툴에서 쓰이는 의미를 익혀야 한다는 것입니다.
그 의미는 간단한 JMeter의 예를 들어 설명하겠습니다.
JMeter 간단예제
누누히 말하지만 아무 생각없이 했으면 좋겠다.
일단 좌측의 노드에 'Test Plan' 이라는 개념에 대해서 알아볼 필요가 있다.
Test Plan 이란 테스트 계획을 나타낼 일련의 실행 코드 집합 이라고 말할수 있다고 한다. 이건 뭔소리인가???
A complete test plan will consiste of one or more Thread Groups, logic conrollers, sample generating controllers, listeners, timers, assertions, and configuration elements.
테스트 플랜은 여러가지 element 들을 가질수 있는데 이것들에 대해선 밑에서 알아보기로 하자.
다음은 Test Plan 노드를 선택하였을 경우 나오는 화면이다.
중간에 User Defined Variables 라고 나오는데 이건 뭔지 저도 잘 모르겠다.
암튼 분명한건 여기서 정의한 변수 및 값은 테스트 플랜 이하 노드에서 모두 상속받아 사용한다는 겁니다.
다음에 체크박스 두개가 있는데 첫번째 'Run each Thread..' 요놈은 Thread를 순차적으로 실행 하겠냐 아니면 동시에 실행하겠냐의 여부를 묻는데 체크하지 않으면 동시에 실행 하는걸로 되어 있습니다. 여기서 Thread란 조금 후에 설명 하겠습니다. 두번째 체크박스는 각 요청에대한 서버의 응답 데이터를 파일에 기록할 것인지 여부를 말하는 것인데 이걸 체크하면 성능이 확~ 떨어지니 왠만함 하지 말라고 되어있습니다.
본격적으로 시작을 해보면 일단 Test Plan에 오른쪽 버튼을 클릭해보자..
이때 나를 긴장시키는 것들이 등장한다.
Thread Group , Listener, Config Element, Assertions, Pre Processors, Post Processors, Timer 들 말이다.
하지만 긴장하지 마3 알아보면 되니까 우린 이 엘리먼트들의 서브 엘리먼트 들에 대해서 다 알아보지는 않을 것이다. 하지만 확실한 건 이것들에 대해서 만큼은 확실한 개념을 정립하여
밑에 있는 서브 엘리먼트들을 알아서 활용할 수 있게끔 하겠다.
'Thread Group'을 선택한다.
Thread Group 이란 테스트 계획을 수행할 수행 단위 그룹이라 보면 될것 같습니다. 이 Thread Group을 여러개 추가 할 수도 있으며 그럴 경우 위에서 언급한 체크박스로 동시에 실행 할 것인지 순차적으로 실행 할 것인지 결정 해야 합니다.
가운데 체크박스 3개가 있네요
이건 만약 테스트 수행도중 에러(테스트 대상의 에러)가 발생 한 경우 계속할 것인지 Thread만 멈출 것인지 아니면 테스트 자체를 멈출것인지를 선택합니다 여기선 그냥 'Continue'로 하지요
그다음 항목이 가장 중요하므로 잘 숙지해야 합니다.
Number Of Threads 란 이 Thread Group이 생성할 Thread갯수를 말하는데, 쉽게 말하면 이 그룹에서는 몇 사람으로 테스트 할 것이냐 라고 생각하면 됩니다.
Ramp-Up Period (in seconds)는 한 Thread가 시작 된 후 다음 Thread가 시작 될 때까지의 대기 시간을 의미합니다 예를 들어 보자면 10개의 Thread가 사용되고 Ramp-up Period가 50이라면 총 10개의 Thread가 모두 실행되려면 50초가 걸린다는 겁니다. 즉 평균적으로 보자면 한 Thread가 실행 후 다름 Thread까지 5(50/10)초정도 후에 실행 되다는 거지요 (휴 어렵다 =3)
Loop Count는 실행 횟수를 말합니다. forever에 체크하면 무한 루프를 돕니다. 이때는 사용자가 수동으로 STOP 시켜줘야 합니다.
이제 Thread Group 에 마우스를 오른쪽으로 클릭 후 'Add -> Config Element -> HTTP Request Defaults'를 선택합니다.
여기서 하나 Test Plan 의 sub element인 Config Element 가 나왔는데 이것은 말 대로 환경 설정 Element 입니다.
여기서는 HTTP Request Defaults를 선택하였는데 이것을 해석해 보자면
HTTP request를 설정함에 있어서 이 노드 이하의 HTTP request는 모두 HTTP Request Defaults에서 설정한 값을 디폴트로 상속 받아 사용하겠다는 겁니다.
반드시 추가해야 할 필수 요소는 아닙니다만 이후의 추가해야 할 HTTP Request노드가 많다면 일일이 다 다음과 같이 세팅해야 함으로 이를 추가해 놓는 편이 좋습니다.
Protocol에는 당연히 웹이니 HTTP를 써야겠고 Server name or ip에는 연결할 서버의 이름이나 ip를 적습니다. 주의할것은 주소까지 모두 여기에 적으면 안됩니다. 나머지 부분은 path 부분에 적어야 합니다.
하지만 위의 설정값 세팅으로 완료된 것이 아닙니다. 이제부터 테스트 실행을 하기 위한
실질적인 노드를 추가해야 합니다.
Thread Group 에 오른쪽 마우스로 클릭하여 'Add -> Sampler -> HTTP Request'를 선택합니다.
HTTP Request는 HTTP요청을 웹서버에 전송하여 그 결과를 받아오는 Sampler입니다.
우리는 좀전에 세팅한 HTTP Request Default의 값을 모두 상속하여 사용할 것이기 때문에 여기서 특별히 세팅할 것이 없습니다.
그럼 여기서 Test Plan 기능중 하나인 Sampler라는 개념이 등장합니다.
샘플러는 테스트 서버에게 HTTP 요청을 보내고 싶으면 HTTP 요청 샘플러를, FTP 요청을 보내고 싶으면 FTP 요청 샘플러를 추가하면 됩니다.
Sampler 메뉴의 하위 메뉴를 보게 되면 정말 다양한 요청들이 존재함을 알 수 있다.
만약 서버에 같은 타입의 요청을 다중으로 보내고자 한다면 Config Element의 디폴트 요소를 사용하는것이 편리합니다. (예: HTTP Request Default) 아까 배웠당..
이제 request에 대한 준비는 되었고.. 이제 그에 대한 응답을 어떻게 분석 할 것인지에 대해 준비를 해 봅시다.
Test Plan 를 역시나 오른쪽 마우스로 클릭하여 'Add -> Listener -> View Results Tree와 Graph Results'를 추가합니다
여기서 또한 Test Plan 기능중 하나인 Listener 라는 개념이 등장합니다.
Listener 란 테스팅한 결과의 정보를 나타내는데 사용됩니다. 즉 결과를 레포팅 해주는 것이죠
어떤 위치든지 추가될 수 있으며 그 요소에 해당하는 데이터나 그 이하 노드에 해당하는 데이터들만 수집하게 됩니다.
이제 상위 메뉴중 'RUN -> START'를 클릭해봅시다.
그러면 우측 상단에 있던 아주 자그마한 네모박스가 연두색 으로 표시됩니다. 이 표시가 현재 테스트중이라는 표시입니다. Thread Group에 세팅된 정보에 의해 딱 10번 request가 가게 될 것입니다.
결과물 reporting은 IDE Using JMeter 를 참조하자
Elements of a Test Plan
이제 본격적으로 Test Plan의 Elements 들의 내용들을 살펴보기로 하겠다.
Thread Group
쓰레드 그룹은 테스팅에 있어 시작점이 되며 모든 요소들은 최소한 하나의 쓰레드 그룹에 속해야 합니다.
Controller
컨트롤러란 서버에 테스트 요청을 전달 할 때 무엇을 언제 보낼지를 지시합니다.
샘플러(Sampler, 무엇을)와 로직(Logic Controller, 언제) 두가지 타입이 있습니다.
Samplers
샘플러는 테스트 서버에게 HTTP 요청을 보내고 싶으면 HTTP 요청 샘플러를, FTP 요청을 보내고 싶으면 FTP 요청 샘플러를 추가하면 됩니다.
Logic Controllers
로직 컨트롤러는 언제 요청을 전달해야 하는지 결정합니다. 다음 예를봅시다.
HTTP default request와 Cookie Manager가 Thread Group에 추가되어 있다는 것을 유의깊게 봅시다. 그리고 Interleave Controller에도 HTTP default request가 있습니다.
① Once Only 컨크롤러에 의해 로그인 요청은 딱 한번 요청이 됩니다. 이후의 반복작업에서는 이 작업이 스킵이 되게 됩니다.
② 그다음 검색 페이지를 요청합니다. 이 요청은 어떠한 컨트롤러도 개입이 되어있지 않습니다.
③ 검색페이지에서 "A"를 검색합니다. Interleave 컨트롤러의해 다음 반복 작업때에는 "B"를 검색합니다. 즉 순서를 돌아가며 실행 된다는 것입니다.
Listeners
리스너는 테스팅한 결과의 정보를 나타내는데 사용됩니다. 즉 결과를 레포팅 해주는 것이죠
어떤 위치든지 추가될 수 있으며 그 요소에 해당하는 데이터나 그 이하 노드에 해당하는 데이터들만 수집하게 됩니다.
가장 간단한 Graph Result 리스너는 응답시간을 그래프에 뿌려줍니다.
Timers
기본적으로 JMeter는 요청들을 쉴틈없이 테스트 서버로 보내게 되는데 만약 아주 짧은 시간에 상당한 양의 요청들을 보낸다면 서버가 뻗어 버릴지도 모릅니다.
타이머는 쓰레드가 만들어 내는 각 요청들 사이에 특정 시간만큼 딜레이를 주는 역할을 합니다.
Assertions
어서션은 테스트 요청에 대한 응답이 제대로 된 응답인지 그 유효성을 검증해줍니다.
예를들어 테스트 요청에 대한 응답이 어느 특정 텍스트를 포함하고 있는지를 확인 해 볼 수 있다는 것입니다.
어서션의 결과를 볼려면 어서션 리스너를 추가해야 한답니다.
Configuration Elements
Sampler와 굉장히 긴밀한 관계가 있으며 환경 설정 전역적인 역할로 쓰입니다.
실전 예제
일단 실전예제로 쓰일 머 이름만 거창하다 뿐이지 사실 실전예제까지는 아니다.
자 그럼 시나리오를 세워보자
1. 일단 www.naver.com에 접속한다.
2. 내 아이디로 로그인 한다.
3. 2초를 쉰다.
4. naver 지식in 메뉴로 들어간다.
– 검색은 랜덤하게 일어난다. ----------------
5. 지식검색으로 '강정화'를 검색한다.
6. 지식검색으로 '한채영'을 검색한다.
------------------------------------------
7. 통합검색으로 박지성을 검색한다.
8. 검색한 것에 '닝기리'가 존재하는지 검사한다.
자 그럼 한번 Test Plan을 만들어 보겠다. Test Plan 이름은 Naver 검색 Test Plan 이다.
자세한 것은 스터디 시간에 야그 하겠다.
만약 여러분들이 이걸 익혔다면 정말 JMeter의 기능을 대략적으로 익힌 것이다. 이젠 우리 구미에 맞는 Test Plan을 찾을 수 있으며
이 사이트는 강추로 추천한다. 꼭 보시길 바란다.
http://jakarta.apache.org/jmeter/usermanual/component_reference.html
참고 문서
- 튜닝 - 시스템 일반
: 시스템 Tuning과 관련한 유용한 문서들을 정리해 놓았습니다.
- Performance Tuning QuickGuide for BenchmarkTest
- 웹기반시스템하에서의 성능에 관한 이론적 고찰
- Tuning Your Stress Test Harness
- IDE:Using JMeter - JMeter사용하기(자바지기님 개인적으로 정리했던 문서입니다. 이상한 부분이 있으면 저희쪽에도 나중에 고쳐주시기 바랍니다. ^^)
======================