[Java Test] 4. Jmeter 성능테스트

 

---

 

Contents

 

 

 

성능 테스트

기본적으로는 Apache bench(ab)등으로 API 테스트를 해도 쉽다. 

https://httpd.apache.org/docs/2.4/programs/ab.html

ab - 아파치 웹서버 성능검사 도구 - Apache HTTP Server Version 2.4

 

java의 경우 Jmeter를 많이 쓰는데, 성능 측정 및 부하 (load) 테스트를 할 수 있는 오픈 소스 자바 애플리케이션이다,

https://jmeter.apache.org/

XML으로 테스트할 수 있고, 자바 개발자에게 가장 잘 알려져있다.

Apache JMeter - Apache JMeter™

 

JMeter 기능

- 다양한 애플리케이션 테스트 지원

• 웹 - HTTP, HTTPS
• SOAP / REST 웹 서비스
• FTP
• 데이터베이스 (JDBC 사용)
• Mail (SMTP, POP3, IMAP)

- CLI 지원

• CI 또는 CD 툴과 연동할 때 편리함.
• UI 사용하는 것보다 메모리 등 시스템 리소스를 적게 사용.

- 주요 개념

• Thread Group: 한 쓰레드 당 유저 한명
• Sampler: 각각의 유저가 해야 하는 액션 (예) Http 요청)
• Listener: 요청에 따라 응답을 어떻게 처리할 것인가. (예) 리포팅, 검증, 그래프 그리기 등
• Configuration: Sampler 또는 Listener(애매)가 사용할 설정 값 (HTTP헤더, 쿠키, JDBC 커넥션 등)
• Assertion: 응답이 성공적인지 확인하는 방법 (응답 코드, 본문 내용 등)

- 대체제:

• Gatling : 코드로 테스트 작성 가능
• nGrinder : https://naver.github.io/ngrinder/ 네이버에서 만든 툴

 

Jmeter 설치

1) 다운로드

https://jmeter.apache.org/download_jmeter.cgi에서 Binary의 apache-jmeter-5.5.zip를 다운받고 압축을 푼다.

 

2) jmeter 실행

- 압축을 푼 폴더의 apache-jmeter-5.5\bin로 이동

- 맥, 우분투 : cmd에서 jmeter를 실행

- 윈도우 : jmeter.bat을 실행

 

조금 기다리면 이런 GUI 툴이 실행된다.

 

 

 

Jmeter사용법

우선 성능테스트를 할 RestAPI를 만든다.

@RestController
@RequiredArgsConstructor
public class TeamController {

    final TeamRepository repository;

    @GetMapping("/team/{id}")
    public Team getTeam(@PathVariable Long id){
        return repository.findById(id).orElseThrow(()->new IllegalArgumentException("Team not found for " + id));
    }

    @PostMapping("/team")
    public Team createTeam(@RequestBody Team team){
        return repository.save(team);
    }
}

이 때 성능테스트를 할 서버와 테스트를 돌리는 서버가 서로 달라야한다.

같은 서버에서 성능 테스트와 api를 둘 다 돌리면 서로 자원을 먹기 때문에 정확한 성능 테스트가 어렵다.

 

테스트는

1. 스레드 그룹 만들기 (유저 수 설정)

2. 샘플러 만들기 (각각 유저가 해야할 일)

3. 리스너 만들기

4. 실행

 

1) Thread Group 만들기

Test를 우선 저장하고, Add -> Threads(Users) -> Thread Group을 클릭한다.

• Number of Threads(users): 쓰레드 개수(유저 수)
• Ramp-up period: 쓰레드 개수를 만드는데 소요할 시간
• Loop Count:
  - infinite : 쓰레드(유저) 개수대로 계속 요청
  - 값 입력 시 (해당 쓰레드 개수x루프 개수) 만큼 요청

이 부분은 에러 발생 다음 액션으로, 에러 발생 여부는 Assertion으로 확인할 수 있다

 

 

2) Sampler 만들기

샘플러는 유저의 행동, 유저가 할 일, 즉, 테스트 내용이다

다시 오른쪽 버튼을 눌러서 Add -> Sampler -> HTTP Request를 선택한다 (Rest Api를 테스트할 예정)

• 요청을 보낼 호스트, 포트, URI, 요청 본문(Body) 적기
• 여러 샘플러를 순서대로 등록도 가능

 위에서 만들었던 Get Request를 호출할 예정.

 

3) Listener 만들기

똑같이 테스트명 위에서 오른쪽 버튼을 눌러서 Add-Listner를 추가해주는데

• View Results Tree
• View Resulrts in Table
• Summary Report
• Aggregate Report
• Response Time Graph
• Graph Results

여러 리스너를 선택할 수 있다.

 

 

4) 실행

상단 Play버튼을 누르면 테스트가 실행된다.

View Result Tree를 보면 해당 테스트에 대한 상세 내용을 보여준다.

 

View Result in Table로 보면 내용을 요약해서 볼 수 있는데,

첫번째 Test Latency(Time)이 좀 긴 것을 볼 수 있다.

cf) 첫번째 요청은 서블릿을 만드느라 좀 오래걸린다. 이후에는 만들어져있기 때문에 시간이 적게 걸린다.

 

Summary를 보면 평균적으로 44m/s 걸렸고, 가장 빠른 것은 11, 가장 늦은 것은 308로 나온다.

Error는 없고, Throughput은 1.1/sec인데 보낸 요청이 적기 때문에 초당 1.1로 나오는데

많은 요청을 보내보아야 tpc(transaction per sec)를 알 수 있다. 

 

Aggregate는 summary와 비슷한데

Median(중앙값)은 데이터 셋의 중간값 (값 개수 짝수면 평균값)을 이야기한다.

90% line은 이 중 90%는 22m/s안에 처리되며

99% line은 이 중 99%는 308m/s안에 처리된다는 내용이다. (가장 첫 오래 걸린 내용이 포함됨)

Response 그래프는 실제 추이를 그래프로 확인할 수 있다.

횟수가 적은 것보다는, Thread group에서 횟수를 infinite로 두고, Graph setting의 Interval을 1000(1초)로 두면

이런 형태로 그래프를 그릴 수 있다. 실시간으로 갱신되지는 않아서 Settings 탭과 Graph를 번갈아서 눌러주면 갱신된 그래프를 확인할 수 있다.

 

지금은 로컬에서 테스트와 Api를 둘 다 돌리고 있어서 정확한 값은 나오지 않으나 그래도 10~12초 아래로 계속 확인되고 있다

 

 

5) Assertion 만들기

assertion으로 원하는 값이 나오는지를 확인할 수 있다.

추가는 역시 테스트명 위에서 오른쪽 버튼 -> Add -> Assertion -> 원하는 assrtion 추가

• 응답 코드 확인 : Response Assertion
• 응답 본문 확인 : JSON Assertion

Response Assertion을 선택하면 Field Test에서 원하는 결과값을 선택할 수 있다

사진처럼 Response Code를 선택하고 아래 원하는 값을 입력해준다.

만약 401을 적으면 원하는 값이 나오지 않기 때문에 테스트가 실패하게 된다.

 

마찬가지로 JSON Assertion으로는 Json 결과값을 확인할 수 있는데

team의 Name값이 Sales로 나오는지 확인하기 위해 테스트를 실행하면

마찬가지로 name이 Software이기 때문에 테스트가 실패한다

 

6) CLI 사용하기

GUI 툴에서 사용하면 CI, CD와 연동이 어려우므로 CLI에서 사용하는 방식을 쓴다 .

Thread Group을 infinite로 두고, Aggregate Report만 두고 저장한 상태로 GUI는 종료한다.

 

cmd에서 저장된 test 파일 폴더로 이동해서 

jmeter -n -t 설정 파일 -l 리포트 파일

로 실행한다.

infinite로 실행했기 때문에 계속해서 테스트가 돌아간다

+는 그 기간동안의 내용, =는 총합을 알려준다.

그 기간동안 application의 내용이 확인된다.

응답시간을 일부러 느려지게 조작하거나, 실패하도록 조작하면 CLI에서 확인이 된다.

 

 

Continuous Test

BlazeMeter라는 플러그인을 쓰면 계속해서 테스팅을 할 수 있다.

크롬에서 실행한하는 액션을 jmeter 파일로 떨어뜨려서 샘플 데이터로 만든다.

성능테스터의 자동화도 가능하다.

https://www.blazemeter.com/

https://chrome.google.com/webstore/detail/blazemeter-the-continuous/mbopgmdnpcbohhpnfglgohlbhfongabi

BlazeMeter | The Continuous Testing Platform

 

 

 

 

출처 : '더 자바, 애플리케이션을 테스트하는 다양한 방법'(백기선), 자료&30~32강