2008년에 작성했던 Apache JMeter 문서.

1. JMETER를 이용한 웹 성능 테스트 방법
작성자 : 용영환 ooti@phpk.org
개요
 목적
 JMeter를 개인이 PC에 설치하여 수시로 편리하게 성능을 테스트하고 그 결과를 통해 개발을 더 잘 할 수 있도록 돕는다.
 그러므로 JMeter를 어떻게 사용하고 결과를 어떻게 도출하는지, 그 결과를 통해 개발에 어떻게 반영할 수 있는지에 대한 방법을 살펴보자.
 주제
 JMeter를 이용한 Java 성능 분석 방법
웹 서비스 성능 테스트의 필요성
일반적으로 웹 서비스의 성능이라면 동시에 얼마나 많은 HTTP 요청을 빠르게 처리할 수 있는가를 말한다. 다른 말로 스트레스 테스트라고도 하는데 이러한 테스트를 하는 이유는 두 가지를 알기 위한 것이라고 말할 수 있을 것이다.
- 서버가 정상적으로 응답을 할 수 있는 동시 최대 HTTP 요청 수
- 서버가 정상적으로 응답할 수 있는 한계 HTTP 요청 상태에서의 응답 시간
웹 서비스에서 동시라는 말은 이상할 수 있다. 웹 특성상 물리적인 동시란 있을 수 없다고 생각할 수도 있기 때문이다. 웹 서비스에서의 동시는 기준에 따라 다를 수 있지만 일반적으로는 1초 이내를 동시라 말하는 것 같고 이 글에서도 동시를 1초 이내라고 하겠다.
지피지기
개인이든 운영하는 웹 서비스의 성능의 한계를 알고 있다면 서비스를 원활하기 위해서는 몇 대의 서버가 필요한지, 성능상의 문제는 없는지를 파악하는데 도움이 될 것이다. 만약 자신이 관리하고 있는 웹 서버가 동시에 100명이 접속했을 때 장애가 발생할 정도로 부하가 심하다면 서버를 늘리거나 여러 가지 튜닝을 고민해 볼 수도 있을 것이다. 이 글에서는 성능을 테스트 하는 방법과 결과를 이해하는 방법을 살펴 볼 것이다.

2. 그동안 자신이 개발하는 웹 서비스에 대한 성능이 어느 정도 인지 알 지 못했다면 이번 기회를 통해 알 수 있기를 바란다.
Apache JMeter란
웹 서비스 성능을 테스트를 수행하는 툴은 Apache JMeter를 비롯하여 AB(Apache Bench), HttpUnit 등이 있다. Apache JMeter는 기능 수행 테스트와 성능 측정을 위한 Java 데스크톱 응용 프로그램이다. JVM 이 설치돼 있는 어떤 환경에서도 구동이 가능하며 데스크톱 환경을 제공하기 때문에 직관적인 인터페이스를 통해 쉽게 사용할 수 있다.
Apache JMeter는 웹 서비스를 비롯하여 파일, 서블릿, Perl 스크립트, Java 객체, 데이터베이스와 쿼리, FTP 서버 등 동적, 정적인 모든 자원을 테스트 할 수 있다. Apache JMeter를 이용하면 서버나 네트웍, 객체에 대한 부하를 시뮬레이션 할 수 있고 다양한 부하 조건에서의 종합적인 성능을 분석 할 수 있다. 또한 서버나 스크립트 등에 대한 동시 다발적인 부하 테스트를 하고 그 성능 분석 결과를 보기 쉽게 도표로 그릴 수도 있다.
JMeter 시작하기
JMeter를 사용하기 위해서는 우선 JVM 이 설치돼 있어야 한다. Apache JMeter(이하 JMeter)는 100% 순수 Java로 개발된 데스크톱 응용 프로그램이므로 JVM 이 설치돼 있는 어느 환경에서든 구동된다. JVM 는 http://java.sun.com/javase/downloads/ 에서 내려 받을 수 있다.
이제 JMeter를 설치해야 한다.. JMeter는 http://jakarta.apache.org/jmeter 에서 내려 받을 수 있다.
JMeter 웹 사이트 왼쪽에 Download Releases 를 클릭하여 JMeter Downloads 페이지로 이동한다. JMeter는 바이너리와 소스 두 가지 형태로 제공되는데 이 문서는 바이러니 형태의 파일을 내려 받아 사용하며 JMeter 버전 2.3.2 를 기준으로 작성한다..
JMeter 의 실행 환경
JMeter는 100% Java 응용 프로그램이기 때문에 다양한 환경에서 동작이 가능하다. 동작이 가능한 환경은 아래와 같다.
- JVM 1.4 이상
- Unix ( Solaris, Linux, etc ), Windows 98 이상 ( NT, XP, Vista 등 ), OpenVMS Alpha 7.3+

3. JMeter 설치 및 실행
사내 개발 환경이 Windows XP 이므로 Windows 버전에 대해 설명한다. JMeter 는 압축을 풀고별도의 설치과정 없이 바로 실행이 가능하다. 그러므로 실행을 고려하여 원하는 폴더에 압축을 푼다.
압축을 풀고 bin 폴더 아래 jmeterw.cmd를 실행하면 된다. 만약 Windows 98 이하인 경우에는 jmeter.bat 를 실행해야 한다.
그림 1 JMeter 실행 파일
JMeter UI
JMeter 실행 화면
JMeter를 실행하면 아래 그림과 같은 화면을 볼 수 있다.

4. 그림 2 JMeter를 실행한 화면
JMeter 상단에는 메뉴가 있고 왼쪽에는 Test Plan과 WorkBench로 구성된 Tree가 있다.
Test Plan
JMeter 화면 왼쪽 Tree 에서 Test Plan을 선택하면 아래 그림과 같은 화면을 볼 수 있다. Test Plan의 화면에서는 테스트를 위한 전반적인 설정을 할 수 있다.
그림 3 Test Plan 화면
Test Plan의 화면에 대하 설명은 다음과 같다.

5. 요소 설명
Name
Test Plan이 이름
Comment
설명
User Defined Variables
사용자 정의 변수
Run Thread Groups consecutively
Thread Group의 연속 실행 지정
Functional Test Mode
기능 테스트 모드
Add directory or jar to classpath
JAR classpath 추가
Library
추가된 jar 목록
표 1 Test Plan 화면 설명
사용자 정의 변수 지정
Test Plan의 사용자 지정 변수는 하위에 있는 모든 테스트 그룹에서 전역 변수의 역할을 한다. 예를 들어 SERVER 라는 변수를 추가하는 경우 이 변수는 하위 모든 Thread Group에서 사용할 수 있다.
아래 그림과 같이 사용자 정의 변수를 추가했다면
그림 4 Test Plan에 사용자 정의 변수를 추가한 화면

6. 그림 5 Thread Group에서 사용자 정의 변수를 사용한 화면
Thread Group 과 같이 하위 다른 요소에서 ${사용자변수} 와 같은 형태로 사용할 수 있다. 위 그림의 경우에는 Test Plan에서 LOOPCOUNT 를 20으로 지정했으므로 Thread Group을 실행 시키는 경우 20번 반복하게 된다.
웹 서비스 성능 테스트
웹 서비스는 여러 시스템이 유기적으로 연결돼 있기 때문에 테스트도 다양한 관점에서 살펴봐야 할 것이다. 그 중에서도 대표적으로 웹 브라우저를 통해 접속하여 서비스를 사용하는 사용자 측면에서 서비스에 문제가 없는지를 판단하기 위한 HTTP Request 테스트가 있다.
HTTP Request 테스트란 사용자가 웹 서버에 접속 했을 때 그에 대한 응답 속도를 측정하는 테스트로써. JMeter 는 마치 사용자가 접속하는 것과 같은 HTTP Request를 웹 서버로 보낸다. 이 과정을 통해 HTTP 요청 부하에 따른 응답 속도를 측정하게 되면 이 결과는 웹 서비스(웹서버)의 임계치를 확인하는 매우 중요한 자료가 된다. 테스트 결과는 웹 서버의 가용 정도를 파악하거나 성능을 향상 시키기 위한 근거 자료로 활용 할 수 있을 것이다.
JMeter 기본 테스트 순서
JMeter를 이용해 성능을 테스트하는 방법은 아래와 같은 순서로 진행된다.
1. Test Plan 작성
2. Thread Group 추가
3. Sample 추가

7. 4. 결과 출력을 위한 Listener 추가
5. 결과 분석
Test Plan 작성
Test Plan에는 어떻게 테스트를 진행할지에 대한 계획을 입력한다. 앞서 설명한 바와 같이 Test Plan에서는 사용자 변수를 정의할 수 있고 테스트를 위한 Thread의 실행 방식을 지정할 수 있다.
Run Thread Groups consecutively 옵션은 Thread Group이 여러 개 있는 경우 순차적으로 하나씩 실행된다. 예를 들어 아래와 같이 다수의 Thread Group이 존재하는 경우 이 옵션을 지정하지 않는다면 5개의 Thread Group이 동시에 실행된다.
그림 6 추가된 Thread Groups
모든 Thread가 동시에 실행되면 그만큼 PC의 자원을 많이 사용하기 때문에 테스트 결과에 영향을 미칠 수 있다. 그러므로 꼭 필요한 경우가 아니라면 순차적으로 Thread를 실행하는 것이 좋다.

8. Thread Group 추가
하나의 Thread 는 한 명의 유저를 의미한다. Thread Group은 유저의 집합으로써 Number of Threads의 값으로 가상의 유저 수를 지정할 수 있다.
Ramp-Up Period는 Number of Threads에서 지정한 수만큼 Thread 가 실행되기까지 걸리는 시간이다. 아래 그림에서는 60개의 Thread가 60초 이내에 모두 실행되도록 한다.
그림 7 Thread Group
여기서 꼭 알아야 할 점은 실행되는 Thread 수가 지나치게 많은 경우 결과 값에 잘못 된 영향을 미칠 수 있다. 예를 들어 JMeter에서 Run을 했을 때 CPU 사용률이 100% 이상이 되면 측정된 응답 시간이 늦어지는 현상이 발생한다. 이는 CPU 자원이 부족하기 때문에 정착 테스트를 위해 동작하고 있는 thread 들이 제대로 실행되지 못하기 때문이다. 그러므로 Number of Threads 값은 자신의 PC 의 성능에 맞게 최대값을 조절할 필요가 있다. 아래 그림은 Intel Core2 Duo 2.40 CPU를 사용하는 PC에서 Number of Threads 값을 100으로 했을 경우에 CPU 사용률이 100%가 된 화면이다.
그림 8 CPU 사용량이 100% 인 화면

9. Sampler 추가
Sampler는 JMeter에서 제공하는 테스트 액션이다. Thread Group을 마우스 오른쪽 버튼으로 클릭한다. Add -> Sampler 아래에서 원하는 Sampler를 선택하면 된다. 여기서는 HTTP Request 를 선택한다.
그림 9 Sampler를 추가하는 화면
Sampler는 테스트 결과를 파일로 저장할 뿐 화면에 보여주지는 않는다. 결과를 그래프나 도표로 보기 위해서는 Listener를 추가해야 한다.
아래는 HTTP Request Sampler를 추가하여 설정하는 화면이다.
그림 10 HTTP Request 추가 화면
접속하려는 URL 의 서버 주소 또는 IP를 입력한다. 그리고 오른쪽에 Port를 입력한다. URL에서 서

10. 버 IP와 Port를 제외한 나머지 경로는 Path 란에 입력한다. Parameter 값인 QueryString 은 그 아래 Send Parameters With the Request 란에 추가한다.
Listener 추가
Listener는 Sampler 를 통해 얻은 테스트 결과를 다양한 형태로 보여주거나 다른 형태로 결과를 저장할 수 있다.
그림 11 Listener 선택 화면
Sampler가 HTTP Request인 경우 Listener는 Graph Results, View Results in Table, Summary Report를 추가하면 된다.
Thread Group 실행
지금까지 Thread Group을 생성하고 Sampler와 Listener를 추가하는 과정을 모두 마치셨다면 아래 JMeter의 화면 왼쪽 Tree 에 그림과 같이 생성되어 있을 것이다.
그림 12 Thread Group이 추가된 화면
이제 추가한 Thread Group이 제대로 동작하는지 실행을 해보겠다. JMeter 상단 메뉴에서 Run ->

11. Start 를 클릭한다. 그럼 상단 오른쪽에 숫자가 증가하는데 앞 숫자는 현재 실행 중인 Thread 수이며 뒤 숫자는 Number of Threads에서 지정한 Thread 수 이다.
Listener로 추가한 View Results in Table, Graph Result, Summary Report를 보면 아래와 같이 결과가 보여질 것이다.
그림 13 Graph Results
그림 14 View Results in Table
그림 15 Summary Report
제약사항을 설명하면 좋을 것 같다.
테스트 결과 분석
테스트 결과를 분석한다는 것은 결과를 통해 얻은 데이터를 바탕으로 보다 나은 서비스를 제공할 수 있도록 시스템을 개선하려는 궁극적인 목적이 있을 것이다.
HTTP Request 테스트로부터 우리가 얻을 수 있는 것은 서비스 또는 서버가 감당할 수 있는 동시 접속자 수는 몇 명이고 이 때의 서버 응답 속도는 어느 정도 되는지, 이를 토대로 우리가 세운 목표 성능을 제공하기 위해서는 시스템 구성은 어떻게 해야 하는지를 고민하기 위해서 일 것이다.

12. 일반적인 응답 지연 시간에 대한 임계 값
웹 서비스를 이용하는 사용자들의 응답 시간에 대한 일반적인 규칙은 아래와 같다.
표 2 응답 지연 시간에 대한 사용자 영향 응답 지연 시간 사용자에 대한 영향
0.1 초 미만
전혀 문제 없음
1 초 미만
사용자들의 웹 사용 흐름에 방해되지 않음.
10 초 미만
웹 사용에 방해가 되나 대체적으로 응답을 기다림
10 초 이상
불편함을 느끼고 이탈
위와 같은 임계 값은 인간의 인지적 특성에 의해 결정되기 때문에 변경되지 않는 규칙이라고 볼 수 있다. 다만, 문화적 특성에 따라 임계 값이 다소 다르게 나타날 수도 있는데 예컨대 우리나라의 경우 응답 지연 시간이 3초 이상인 경우 불편함을 느끼고 이탈한다는 것이 일반적인 견해인 것으로 생각된다. 이는 국내 인터넷 속도가 다른 나라에 비해 빠른 편이며 이러한 환경에 적응하여 사용자 또한 3초 이내의 응답 속도를 기대하고 적응했기 때문이라고 볼 수 있다. 그러므로 국내 서비스를 위해서는 불편함을 느끼고 이탈하는 임계 값을 3초로 정하겠다.
Graph Results
Graph Result는 모든 샘플 시간 동안 수행한 결과를 그래프로 보여 준다. Graph Result 그래프는 요청에 대한 응답 시간의 분포와 최고 응답 지연 시간(가장 늦은 응답 시간), 응답 시간의 평균, 표준 편차를 보여 준다.
그림 16 Graph Results

13. 표 3 Graph Result 설명 그래프 설명
Data (검정)
한 건의 요청
Average (파랑)
Data 결과의 평균
Median (보라)
Data 결과의 최소, 최대의 중간 값
Throughput (초록)
누적 요청 건수
세로축
응답 시간
가로축
Sample 번호
Data는 그래프에서 검정색 점들이다. 각 샘플들의 응답 시간을 점으로 표시한다. 세로축의 맨 위 시간은 최고 응답 시간으로 가장 늦은 응답 시간을 말한다.
Summary Report
Summary Report에서는 진행했던 테스트에 대한 결과를 한눈에 알 수 있게 표 형식으로 보여줍니다. 최고, 최저 응답 지연 시간과 표준 편차, 누적 요청 건수 등을 알 수 있다.
참고 : 에러가 없는데도 Error 의 Total 값이 0이 아닌 경우
테스트 과정에서 에러가 없음에도 불구하고 Error의 Total 값이 0이 아닌 경우가 있을 수 있다. View Result in Table 을 봤을 때 Sample 1번이 Error 로 돼있을 것 이다. 테스트를 완료하고 다시 테스트를 진행하고자 하는 경우 상단 메뉴 Run -> Clear All 을 통해 결과 값을 깨끗이 지우시기 바란다.

14. 웹 서비스의 성능 임계치 분석 방법
웹 서비스의 기준 성능 정의
성능을 분석하기 전에 우리가 바라는 최상의 성능이 무엇인지 기준 성능을 정의해야 한다. 이전에 설명한 바와 같이 일반적인 사람들의 경우 웹 사이트에 접속한 후 3초 이내에 응답이 없는 경우 웹 사이트를 이탈한다. 여기서 말하는 3초는 사람들이 웹 사이트가 모두 보여지는데 까지 기다리는 임계 값인 것이다. 그렇다면 아무리 늦어도 응답 시간이 3초를 넘겨서는 안 된다. 물론 이용자가 느끼는 3초란 웹 브라우저에서 HTML과 CSS, Javascript 를 모두 파싱해서 완벽한 화면을 보여지는데 걸리는 시간이므로 우리가 JMeter 를 통해 얻는 응답 시간은 3초 미만이어야 한다.
- 이용자의 응답 시간 임계 값 : 3초
- 웹 서비스 응답 시간 임계 값 : 2초 ( Javascript, CSS 에 대한 렌더링 시간을 1초라 가정 )
결국 우리가 바라는 기준 성능은 다음과 같다.
- 웹 서비스(웹서버)는 응답 시간은 2초 이내여야 한다.
웹 서비스의 임계 값 파악하기
기준 성능을 정의했으므로 이제 기준 성능을 보장 할 수 있는 처리량에 대한 한계 값을 알아내야 한다. 우리가 웹 서비스에서 일반적으로 말하는 처리량이란 1초에 처리할 수 있는 요청 수라고 할 수 있다.
Throughput 값의 1은 한 건의 요청에 대해 웹 서버가 200 OK 든 400 Error 든 응답을 마친 경우다. JMeter 에서 Number of threads 값을 10 이라고 지정했을 때보다 100 이라고 지정했을 때 throughput 이 낮은 이유는 응답 속도의 차이 때문이다. 응답 속도가 느리다면 당연히 throughput 수도 낮아질 수 밖에 없는 것이다.
기준 성능과 throughput
기준 성능을 응답 시간 2초 이내로 정했으므로 throughput의 증가에 따른 응답 시간의 변화를 살펴보자.

15. 그림 17 Statistical Aggregate Report
위 그래프로는 정확한 수치를 알기가 어려우므로 확대해서 보는 게 좋겠다. 그래프의 부분을 확대해서 보려면 그래프 위를 마우스 오른쪽 버튼을 누른 채로 영역을 지정해 주면 된다.
그러면 아래 그림 2와 같이 부분만 확대된 그래프를 볼 수 있다. 이 그래프에서 봐야 하는 것은 화살표가 그려진 것처럼 Response Time 값이 2,000 (2초)이 지점의 Throughput 값이다. 그림 2의 그래프에서는 7.5 정도라고 할 수 있다. 그렇다면 테스트를 진행한 웹 서비스는 throughput 이 7.5 일 때 기준 성능에 부합될 것이라고 예상할 수 있다.
그림 18 응답 속도 2초에 대한 throughput
이제는 그래프를 통해 알게 된 7.5 라는 Throughput 값이 실제로 임계 값인지 확인을 해야 한다.
테스트는 되도록 로컬에서 하지 말자. CPU가 100%가 되면 결과를 제대로 도출할 수 없다.