NEST 트랜잭션 부하테스트 [JMeter]

https://effortguy.tistory.com/164

[Spring] JMeter 사용법 - JMeter란?, 테스트 방법

의 spring 기반 부하 테스트 블로그를 보고 참조.

 

 

이번엔 현재까지 만든 api를 테스트 하기 위해 부하테스트를 진행 할 것이다.

 

부하테스트에는 여러가지 툴들이 있다.

그중 유명한 JMeter와 nGrinder가 있지만  비교적 자료 소스가 많고 설치 법과 사용법이 간단해서 JMeter를 고르게 되었다.

 

 

맥 OS인 나는 늘 그렇듯 brew로 설치를 하였다.

윈도우를 사용하다가 맥 OS로 갈아타니 자질구레한 설정까지 신경을 안써도 되서 너무 좋을 것 같다. brew짱

 

우선 대부분의 부하테스트 툴을 사용하기 위해서는 JAVA를 먼저 설치를 해야한다.

하지만 brew를 사용하여 설치하면 이미 내부에서 java를 먼저 설치하고 이후 jmeter를 설치한다.

 

 

Brew를 이용한 설치법

brew install jmeter

 

jmeter를 실행법

open /usr/local/bin/jmeter // 대부분 이 루트로 가능

하지만 저 루트에 jmeter가 없어 명령어가 실행이 안될 결우 which 를 사용하여 jmeter의 경로를 확인 한 후

그 경로로 가서 open을 하면 된다.

실행 성공 !

 

 

JMeter 테스트 용어

 

테스트 들어가기 전 JMeter 테스트 용어부터 알아보자.

 

- Thread Group : 테스트에 사용될 쓰레드 개수, 쓰레드 1개당 사용자 1명

- Sampler : 사용자의 액션 (예: 로그인, 게시물 작성, 게시물 조회 등)

- Listener : 응답을 받아 리포팅, 검증, 그래프 등 다양한 처리

- Configuration : Sampler 또는 Listener가 사용할 설정 값 (쿠키, JDBC 커넥션 등)

- Assertion : 응답 확인 방법 (응답 코드, 본문 내용 비교 등)

 

 

1. Thread Group.  테스트할 가상의 유저수를 설정

가상의 5명의 사용자가 1초만에 3번 반복 요청

 

2. Sampler 그 가상의 사용자들이할 것들을 정의

서버 ip와 포트그리고 http 메소드를 명시한다.

 

3. listener

view Results Tree, Summary Report, View Results in Table 를 차례대로 생성해 준다.

그리고 상단 왼쪽에 초록색 실행 버튼을 누르면 아래와 같이 해당 테스트 정보를 파일로 저장할 것이냐는 알림이 뜬 후 실행이 된다.

View Results in Table 로 가보면 이상없이 한번에 5명이 3번의 요청 총 15 번이 잘 실행 됬음을 알 수 있다.

 

응답 body와 headers 등등 도 잘 나온다.

 

Summary Report

또한 시간도 평군 40ms로 큰 지연이 없다.

 

Summary Report 용어 정리

 

- Label : Sampler 명

- # Samples : 샘플 실행 수 (Number of Threads X Ramp-up period)

- Average : 평균 걸린 시간 (ms)

- Min : 최소

- Max : 최대

- Std. Dev. : 표준편차

- Error % : 에러율

- Throughput : 분당 처리량

- Received KB/sec : 초당 받은 데이터량

- Sent KB/sec : 초당 보낸 데이터량

- Avg. Bytes : 서버로부터 받은 데이터 평균

 

등등 여러 기능이 있는 거 같다.

더 많은 기능은 공식문서를 보며 필요한 기능을 찾아서 쓰면 잘 활용할 수 있을 것 같다.

 

 

우선 get 요청에서는  1초에 15번의 요청을 보내도 아무런 문제가 없는 것을 알 수 있다.

 

 

본격적으로 부하 테스트를 하는 이유인 트렌젝션에 대한 테스트를 진행 보고자 한다.

우선 로그인 과 회원가입 테스트는 세팅할 게 많아서 놔두고

본 부하테스트를 하는 주요 이유인 트랜잭션 처리에 대한 post 요청을 테스트 해보고자 한다.

이렇게 세팅을 하고 요청의 body값이 중복이 되도 상관없는 리뷰 작성 api로 트랜잭션 테스트를 해보자 !

View Results in Table

오우 나이스 이상 없이 너무 나이스하게 잘 된다.

오히려 이미 많은 데이터가 쌓여있는 get 보다 시간 마저 더 작게 나온다 !

 

암튼 굿

 

차후 필요시 쿠키나 토큰,세션에 대해서도 테스트해 봐도 나쁘지 않을 거같다.