성능테스트 테스트 도구에는 k6
, JMeter
, Locust
, Gatling
등이 있다.
이 중, 자사 SSO 를 개발하고나서 성능테스트도 추후에 진행하겠지만 지금은 우선 모니터링 Prometheus + Grafana를 연동하고 있는데 수집 데이터가 많지 않아 시각화를 하는데 무리가 있어 요청데이터를 늘려 모니터링이 정상적으로 잘 되는지 테스트해보기 위해 회사에서 많이 사용하는 JMeter를 학습하고자 정리해본다.
JMeter는 웹 애플리케이션과 서버의 성능을 테스트하기 위한 오픈소스 부하 테스트 도구이다.
HTTP, REST API, 데이터베이스, FTP, WebSocket 등 다양한 시스템에 대한 부하/스트레스 테스트를 자동화할 수 있다.
다양한 프로토콜 지원
: HTTP, HTTPS, SOAP, REST, JDBC, FTP 등 지원GUI 제공
: 테스트 시나리오를 시각적으로 구성이 가능부하테스트
: 수백~수천명의 동시 사용자 시뮬레이션 가능리포트/그래프 제공
: 요청속도, 응답시간, 성공률 등 시각화확장성
: 플러그인, 스크립트(Javascript, BeanShell 등) 지원CI/CD 연동 가능
: Jenkins, GitHub Action 우선 유의사항으로는 성능테스트 시 같은 리소스를 사용하면 정확한 수치를 잴 수 없어 애플리케이션 서버와 테스트(JMeter)서버는 달라야 한다.
zpi 파일 다운로드 후 압축해제
apache-jmeter-{version}/bin 폴더 아래에
jmeter.bat 파일을 더블클릭하여 실행
실행 완료
실행을 완료하면 아래와 같은 GUI 화면이 나온다.
용어 | 설명 | 예시 |
---|---|---|
Test Plan | 테스트 전반의 구조와 흐름을 정의하는 최상위 단위 | 로그인 → API 호출 → 로그아웃 순서 구성 |
Thread Group | 동시 사용자 수, 반복 횟수 등을 설정하는 실행 단위 | 100명의 가상 사용자를 10분 동안 테스트 |
Sampler | 실제 요청을 전송하는 구성 요소 | HTTP Request, JDBC Request 등 |
HTTP Request | HTTP/HTTPS 요청을 전송하는 샘플러 | /login , /api/data 요청 등 |
Logic Controller | 요청 흐름을 제어하는 로직 블록 | 조건문(if), 반복(loop), switch 등 |
Loop Controller | 하위 요소를 반복 실행하게 만드는 컨트롤러 | 로그인 요청 5번 반복 |
If Controller | 특정 조건일 때만 실행되는 컨트롤러 | 응답값이 200일 때만 다음 요청 실행 |
Assertion | 응답 결과의 유효성을 검증 | 응답 코드가 200인지 확인, 본문에 "success" 포함 여부 등 |
Listener | 테스트 결과를 수집하거나 시각화하는 구성 요소 | View Results Tree, Summary Report, Aggregate Graph 등 |
Timer | 요청 간 지연을 추가 | 사용자 간 1초씩 지연 |
PreProcessor | 요청 전에 실행되는 설정 변수 | 초기화, 동적 파라미터 생성 등 |
PostProcessor | 요청 후 결과 처리에 사용 | JSON 응답에서 토큰 추출 |
Regular Expression Extractor | 응답에서 값을 정규표현식으로 추출 | <token>(.*?)</token> 등 |
CSV Data Set Config | 외부 CSV 파일로부터 데이터 로드 | 사용자 계정 목록 불러오기 |
Variables | 테스트 중 사용하는 변수 | ${username} , ${access_token} 등 |
Functions | 변수 값 생성, 날짜 계산 등을 위한 내장 함수 | ${__time(YMD)} , ${__UUID} 등 |
Assertion Result | Assertion의 성공/실패 결과 | 실패 시 로그에 기록됨 |
Throughput | 일정 시간 내 처리한 요청 수 | 초당 500건의 로그인 처리 |
Latency | 요청 전송 후 최초 응답까지 걸린 시간 | 평균 200ms |
Response Time | 전체 응답을 받는 데 걸린 시간 | 평균 450ms |
Error Rate | 전체 요청 중 실패한 요청의 비율 | 0.5% 오류 발생률 등 |
File
- New
- Test Plan Name 작성
테스트 할 유저를 설정해준다.
Test Plan 마우스 우클릭
- Add
- Threads (Users)
- Thread Group
10명의 유저(Number of Threads (users))가 1초(Ramp-up period (seconds))만에 2번(Loop Count) 반복해서 에러가 발생해도 계속 요청을 보낸다고 설정
옵션 설명
Name
: Thread Group의 이름Action to be taken after a Sampler error
: Sampler로 테스트 중 에러 시 Action 설정Number of Threads (users)
: 유저(Thread) 수. 동시에 몇개의 Thread를 발생시킬 것인지에 대한 옵션Ramp-up period (seconds)
: Thread를 발생시킬 시간Loop Count
: Thread의 반복 시간. n 으로 값을 설정할 수 있으며 설정된 값에 따라 Number of Threads X Ramp-up period 만큼 요청을 다시 보냄요청을 보낼 Request를 작성해준다.
나는 HTTP 기반 요청을 보낼것이기 때문에 HTTP Request
를 추가해주었다.
Thread Group 마우스 우클릭
- New
- Sampler
- HTTP Request
를 선택한다.
x-www-form-urlencoded 형태로 파라미터를 전달을 해야해서 Body data
를 열어서 파라미터를 담아주었다.
위에서 말한 x-www-form-urlencoded 형태로 파라미터를 전달하기 위해 헤더에Content-Type=application/x-www-form-urlencoded
파라미터를 담아주어야 한다.
Thread Group 마우스 우클릭
- Add
- Config Element
- HTTP Header Manager
를 선택한다.
헤더추가
결과를 모니터링 하기위해 Listener를 추가해준다.
HTTP Request 마우스 우클릭
- Add
- Listener
- View Result Tree
, Summary Report
, View Results in Table
응답 검증을 위해 Assertion을 추가해준다.
HTTP Request 우클릭
- Assertions
- Response Assertion
응답 텍스트에 "access_token"
이 담겨있으면 성공으로 응답 Assertion을 작성해주었다.
▶️버튼을 누르면 실행
🧹빗자루 모양 버튼을 누르면 응답 결과를 clear 할 수 있다.
View Results Tree 페이지를 본 결과 응답 데이터에 access_token
을 받아오는 것을 확인할 수 있다.