JMeter를 이용한 과부하 테스트(동시 접속자 테스트)

JMeter를 알아보기 전에 부하 테스트에 대해서 간단하게 알아보자 

 

부하 테스트는 임계치 한계에 도달 할 때까지 시스템의 부하를 지속적으로 증가시켜서 시스템을 테스트하는 것을 의미하는 테스트로 성능(Perfomance) 테스트의 하위 테스트이다

 

부하 테스트의 목적을 한번 더 상기시켜보자면

• 버퍼 오버플로우, 메모리 누수, 및 잘못된 메모리 관리와 관련된 응용 프로그램의 결함을 노출한다
• 부하 테스팅의 결과로 발견되는 문제는 로드 밸런싱 문제, 대역폭 문제, 기존 시스템의 용량 등이 포함된다
• 데이터 베이스, 하드웨어, 네트워크 등의 응용 프로그램의 모든 구성 요소의 상한을 결정한다
• 예상할 수 있는 어플에 대한 부하를 관리 할 수 있도록 한다.

더욱 자세한 내용은 https://latewalk.tistory.com/150 에서 확인 할 수 있다.

성능 테스트, 부하 테스트, 스트레스 테스트

---

JMeter란?

Apache 에서 만든 자바로 만들어진 웹 어플리케이션의 성능 테스트 오픈 소스이다.

 

Jmeter는 Swing으로 제작한 GUI와 CLI 방법을 지원하고 있다.

 

JMeter 용어

• Thread Group : 쓰레드들을 관리하는 곳이다.
  • 모든 테스트 플랜 작성의 시작 지점으로 Thread Group 아래에 모든 컨트롤러와 샘플러가 위치한다.
  • 여기서 Thread, Ramp-up, Loop count 등을 설정할 수 있다.
• Samplers : 요청을 추상화 한 것이다.
  • 해당 구역에서는 FTP, HTTP, SMTP 등 다양한 요청을 할 수 있다.
    
    
• Logic Controller : 요청들을 묶어서 시나리오화 한 것이다.
  • JMeter가 언제 서버에 요청을 전달할 지를 결정한다. 전체 부하 테스트 중에서 로그인은 한번만 한다. 
  • URL을 2개로 만들고 요청의 순서가 존재한다면 HTTP Request Smapler를 2개 등록후 Logical Controller로 2개의 상관관계를 정의 한다.
• Listeners : 테스트 결과를 추상화 한다.
  • Smapler를 이용하여 테스트를 진행하면서 헤더에 토큰을 담거나, 쿠키에 세션을 담는 행위 즉, 로그인 된 사용자의 요청을 테스트에 사용할 수 있다.
• Assertion
  
  • HTTP 프로토콜을 이용해서 성능 테스트를 할 셩우 요청별 성공 / 실패 여부는 HTTP 응답 코드의 값을 이용해서 판단한다. 대부분 200이 성동으로 인식하지만 때론 200 또한 실패로 판단하는 경우가 생기게 된다. 이때 Assertion을 이용해서 응답 정보에 특정한 메세지를 필터링하여 성공 / 실패 여부를 판단 할 수 있다

 

왜 JMeter일까?

• 무료로 사용할 수 있고, 계획한 시나리오 테스트를 진행하는데 기능상 문제가 없다
• 커뮤니티, 래퍼런스가 방대하여 최근까지도 유지보수가 진행되는 중이다
• HTML 형식의 보고서가 풍부한 정보를 제공한다.

 

---

테스트 준비

JMeter는 GUI를 제공하기에 손쉬운 테스트를 진행 할 수 있습니다

1. 테스트 계획에서 하나의 쓰레드 그룹을 생성한다.

 

2. HTTP 요청을 통해 우리가 원하는 요청 하나를 만들어본다.

 

3. 요청을 설정해보자

영어로 적혀있는 분들을 위해서...

• Thread - 동시 접속자 100명
• Ramp-up - 1초 마다 실행한다.
• Loop count - 요청 횟수(무한을 누르면 계속해서 100명이 1초마다 계속 요청한다)
• Same user on each iteration - 각 반복 실행 시 동일 사용자
• 정리하자면 100명이 1초마다 요청하는 것을 1번 실행한다.

이번 실험은 동시 접속자에 대한 실험을 해보는 실험이다. 

 

요청을 확인해보기 위해 Listener 를 사용하는데 이번에 사용할 리스너는 밑에 사진에서 노란색으로 색칠 된 리스너를 사용할 것이다.

 

여기서 jp 로 시작되는 리스너는 jmeter의 플러그인에 해당되는데 노란색으로 칠해져있는것은 응답 시간을 그래프로 확인 할 수 있는 플러그인 중 하나인 Response Times Over Time이다.

참고로 플러그인을 설치하는 방법은 해당 블로그에서 굉장히 잘 설명해주셨다.

https://junap2020.tistory.com/82

[Jmeter] 02_제이미터 플러그인 설치하기

 

테스트 시작

테스트 환경의 설정과 리스너 환경 설정

나는 우선 로컬에서의 서버이용 시간과 EC2 를 이용한 서버의 응답시간이 서로 얼마나 다른지 궁금했다. 각각의 조건은 물론 똑같다. 횟수의 조건이 조금 달라졌다. 1초에 100번 요청하는 것을 5번 반복하는 것으로 지정했다.

 

 

 

테스트 결과 리스너 확인

요약 보고서

• 요약 보고서이다
• 1초에 100번의 요청이 수행되었고 이는 5번 수행되면서 총 500번의 요청 수행을 진행하였다.
• 로컬과 EC2 서버의 값은 물론 편차가 크게 차이나는데 로컬은 0.05초이고 EC2는 2초 정도의 소요시간이 걸리는 것을 알수 있다.
• 다행히 두개의 테스트 모두 오류 0%를 자랑하고 있다
• 처리량은 로컬이 43TPS, AWS가 38TPS를 나타내고 있다. 평균값이 크게 차이나는거 치고는 나쁘지 않다고 생각했다

 

결과들의 트리 보기

두 개의 요청 중 하나씩 가져와봤다. 

• 쉽게 생각하면 브라우저에서 개발자 도구를 생각하면 편하다.
• 각각의 요청에 대한 표본추출기 결과, 요청, 응답 데이터까지 확인 할 수 있다
• 응답 데이터는 응답 body로써 서버가 보낸 정보를 확인하는 곳이라고 할 수 있다.

 

Response Times Over Time

빨간색이 로컬 환경 보라색이 AWS의 환경이다. 

로컬은 굳이 필요없지만 응답시간을 확인해보면 0.02초도 안걸리는 응답시간을 나타내고 AWS서버는 최대 2초 정도의 응답을 나타내고 있다. 응답시간이 2초인 것은 나쁘게 생각하지 않지만 메인 페이지이니 만큼 더욱 빨랐으면 좋겠다는 생각을 한다.

 

응답시간을 줄인다는 것은 TPS를 높이겠다는 뜻이다. 그렇다면 TPS란 무엇이며 어떻게 줄일 수 있을까??

https://latewalk.tistory.com/149

웹 서버 성능 지표(TPS)