jMeter 사용하기 (with MQTT)

1. jMeter?

jMeter는 부하 테스트, 성능 평가를 위해 설계된 자바 기반의 옾느소스 데스크톱 어플리케이션이다. jMeter을 이용하면 Open API 서버의 대한 기능 점검(1), 수용량 측정(2) 및 부하 테스트(3)가 가능하다.

기능 점검

기능 점검은 Open API의 사용자 정보, 게임 정보, 채널 정보 및 컨텐츠 정보 서비스에 포함도니 각각의 API에 대한 정상 동작 유무를 테스트하는 테스트 케이스를 작성한다. 기능 테스트의 목적은 품질 확보이다.

수용량 측정

수용량 측정은 사용자의 서비스 사용 시나리오를 예측하여 시나리오 기반의 테스트 케이스를 작성하고, 이를 이용해 서비스 환경을 시물레이션 한다 . 다수의 가상 사용자가 접속하여 소규모 서버에서 수용 가능한 동시 사용자 수를 산출한다. 수용량 측정은 목적은 시스템 확장 및 운영 계획 수립을 위한 기초 자료 확보이다.

부하 테스트

부하 테스트의 목적은 하드웨어, 소프트 웨어, 네트워크 등 서버 아키텍처 전반에 걸친 안정성 점검, 취약점 분식 및 스케일 자도화의 모의 테스트 이다.

2. MQTT(Message Queuing Telemetry Transport)

MQTT는 ISO 표준 발행-구독 기반의 메시지 프로토콜 이다. 그리고 TCP/IP 프로토콜 위에서 동작한다. ( M2M, IOT에서 주로 사용된다 )

작은 코드 공간이 필요하거나 네트워크 대역폭이 제한되는 원격 위치와의 연결을 위해 설계되어 있다.

발행-구독 메시징 패턴에는 메시지 브로커가 추가로 필요하다.

3. MQTT Qos ( Quality of Service )

QoS는 서비스의 질을 보장해주는 레벨을 의미한다.

사물인터넷은 무선 네트워크망에서 통신한다. 와이파이, 지그비, 블루투스 등을 사용하는데 이런 통신망은 유선망보다 불안정하기에 이러한 불안정함 프로토콜 상에서 안전하게 보완하여 전송하기 위해서는 QoS가 필요하다.

QoS의 레벨은 3가지로 나뉜다.

레벨 0

메시지는 한번만 전달한다. 보내고 잊는다. ( Fire and Forget ), 전달여부는 확인하지 않는다. ( 한번에 전송 성공을 하지 않으면 실패로 끝이난다. )

레벨 1

메시지는 최소 한번은 전달된다. 그렇지만 메시지의 핸드쉐이킹 과정을 엄밀하게 추적하지 않기에 중복전송될 수도 있다.

1. Publisher가 Broker에게 정상적으로 보낸다.

2. Broker는 받은 메시지를 Subscriber에게 정상적으로 보낸다 ( Subscriber 1회 수신 )

3. Broker는 메시지를 보냈으므로 PUBACK을 Publisher에게 보낸다.

4. 그러나 PUBACK이 전달 중에 사라졌다. ( Loss 발생 )

5. Publisher는 PUBACK을 기다리다가, 시간이 지나자 전송이 실패한 줄 알고 다시 Broker에게 보낸다 ( DuplicatePublish )

6. Broker는 메시지에 관한 정보를 삭제했기에, 처음 받는 메시지인줄 착각 하여 다시 Subscriber에게 보낸다 ( Subscriber 2회 수신 )

7. 다시 PUBACK을 보낸고 종료한다.

8. Publisher가 PUBACK을 받으면 통신은 종료된다.

레벨 2

메시지는 한번만 전달된다. 하지만 메시지의 핸드쉐이킹 과정을 추적한다. ( 높은 품질을 보장해주지만 성능의 희생이 따른다. )

1. Publisher가 메시지를 전송한다.

2. Broker가 메시지를 전달한다. ( Subscirber 1회 수신 )

3. Broker가 Publisher에게 PUB Recevied를 전송한다.

4. PUBREC이 분실되어 Publisher가 다시 메시지를 보내도, Broker는 메시지를 이미 갖고 있기 때문에 Subscriber에게 다시 메시지를 전송하지 않고 PUBREC을 다시 전송한다.

5. Publisher는 PUBREC을 받으면, 이제서야 Publish Release 메시지를 보낸다.

6. PUBREL이 loss되는 것은 문제가 없다. 브로커는 이미 메시지 전송한 사실을 알고 있기에 새로 전송하지 않는다.

7. PUB REL받으며, 이제야 메시지를 샂게한다.

8. 메시지를 정상 종료하였으므로 PUBCOMPLETE를 전송한다.

참고 블로그 https://dalkomit.tistory.com/111

간단한(?) 이론 정리가 끝났으니 사용방법

4. jMeter 설치 및 가동

1. 다운로드 http://jmeter.apache.org/download_jmeter.cgi

그 밖의 jMeter Plugin이 많이 존재합니다. 여러가지 도움되는거 설치하시면 좋습니다.

( jMeter디렉토리/lib or jMeter디렉토리/lib/ext 에 다운받은 Plugin( .jar ) 을 넣으시고 재실행 하면 됩니다. )

2. 실행

jMeter 설치 디렉토리/bin/jmeter.bat을 실행하여 실행시킨다.

실행을 시키면 TestPlan 하나만 존재한다. 우클릭 후 Add -> Threads -> 경로에 Thread Group을 추가한다.

Name: 테스트 이름

Comments: 첨부할 설명

Action to be taken after a Sampler error: 샘플러가 에러시에 취하는 행동이다. 보통 Continue를 두면 에러와 무관하게 루프를 돌게된다.

Number of Threads: 쓰레드를 동시에 몇개 생성할지이다. 즉 동시에 몇개의 트랜잭션을 실행시킬지이다.

이는 사람이 동시에 접속하는 효과를 낸다. 10명이서 동시에 접속하는 상황을 만들고 싶다면 10을 사용하면된다.

Ramp-Up Period: 쓰레드를 Ramp-Up Period시간동안 실행해라는 의미이다. 단 균등하게 시간을 나눠서 실행하려고 노력한다. 예를 들어 Nomber of Threads가 10인데 Ramp-Up Period가 60이면 10개의 쓰레드가 6초간격으로 동작하려고 한다. 근데 그렇게 안될 수도 있다.

Loop Count: 스레드의 반복 횟수를 의미한다. 10이면 10번 반복한다. Forever에 체크하면 무한 반복한다.

Delay Thread creation until needed: 스레드의 생성을 필요할 때까지 기다린다. 체크를 해제하면 안기다리고 날리는데 반응성은 더 좋아지긴 하는데 안정성을 위해서 체크해 두자.

Scheduler: 위의 모든 작업을 스케줄화 해서 할 수 있다.

Duration: Scheduler를 체크했을때만 사용가능. Thread Properties의 총작업을 하는 시간을 의미한다. 예를들어 100초를 정하면 위의 작업을 딱 100초동안 실행한다. 100초안에 걸리는 작업이면 조기에 정지되지만 위의 작업이 100초를 넘어간다면 더이상 실행하지 않고 멈춘다.

Startup delay: 위의 작업을 실행하기 위한 유예기간을 의미한다. 쓰레드 그룹이 한개일때는 별 필요없지만 쓰레드 그룹을 여러개 돌릴떄는 서로 차등을 줄 수 있다.

참고블로그 https://kamang-it.tistory.com/entry/JMeter%EC%93%B0%EB%A0%88%EB%93%9C-%EA%B7%B8%EB%A3%B9%EB%A7%8C%EB%93%A4%EA%B8%B0-2

Thread Group으로만은 실행을 시켜도 반응이 없다 Thread Group 우클릭 add -> sample -> HTTP Request를 추가해준다. ( 본인이 필요한거에 맞게 추가한다. )

HTTP Request를 추가하면 조금 친숙(?) 한 창이 뜨게 된다. 자신이 테스트하고 싶은값을 넣어준뒤 12시 방향에 있는 실행 버튼을 이용하여 실행한다. 이렇게 설정한값을은 .jmx 로 파일로 저장이 가능하며 언제든지 불러오거나 할 수 있다.

별도로 프로그램 내부에서 어떻게 가동이 되었고 성공여부를 알고 싶다면 Listener을 추가해주면 된다.

주로 사용하는 Listener은 View Results Tree, Summary Report 등이 있다고 한다.

좌측이 View Result Three 우측이 Summary Report

Samples : 서버에 요청한 횟수

Average : Samples의 평균 응답시간(ms)

Min : Samples의 최소 응답시간(ms)

Max : Samples의 최대 응답시간(ms)

Std. Dev : samples의 표준편차 ( 요청에 대한 응답시간이 일정하고, 안정적인지 확인 값이 낮을수록 안정적)

Error : Error율(%)

Throughput : 초당 처리건수

Received KB/sec : 시간당(sec) 수신한 데이터(KB)

Sent KB/sec : 시간당(sec) 전송한 데이터(KB)

Avg. Bytes : 평균 바이트

참고로 저는 그 밖에 다른 Thread을 설정하고 싶어서 Concurrency Thread Group ( Plugin ) 을 설치하여 사용하였다.

Thread를 몇개로 시작했다 증가시키고 증감시키고 유지하고 등등 가능한 플러그인 이다.

다운로드 https://jmeter-plugins.org/wiki/SteppingThreadGroup/

다운 후 압축파일을 jMeter디렉토리/lib 와 jMeter디렉토리/lib/ext 맞게 넣어주거나 그냥 붙여넣고 덮어쓰기 하면된다.

TestPlan 에서 우클릭 후 Concurrency Thread Group을 생성한다.

설정 그래프

Name:Concurrency Thread Group 이름

Comments: 첨부할 설명

Action to be taken after a Sampler error: 샘플러가 에러시에 취하는 행동이다. 보통 Continue를 두면 에러와 무관하게 루프를 돌게된다.

Target Concurrency: 총 늘어날 Thread 갯수

Ramp Up Time(min): 마지막 Thread 증가까지 걸리는 시간(최종 증가 후 대기시간 까지 포함)

Ramp-Up Steps Count: 마지막 Thread 도달까지의 필요한 증가폭 수 (Target Concurrency/Ramp-Up Step Count 만큼 증가한다.)

Hold Taget Rate Time(min): 최종 Thread 도달 이후 유지되는 시간

 

사진과 같이 자신의 설정값에 맞게끔 그래프가 하단에 생성된다. 조금씩 설정을 변경시키더라도 그래프 모양을 통하여 쉽게 설정값을 한눈에 볼 수가 있다. 그 밖에 Smaple 생성하여 HTTP Requets 작업도 가능하다

Jmeter 확장자 파일은 .jmx 로 저장이된다