cd jmeter/bin
./jmeter-server
# 정상 연결 확인을 위해 jmeter.log 확인 (아래처럼 뜨면 성공)
Writing log file to: /XXXX/XXXXX/bin/jmeter-server.log
Created remote object: UnicastServerRef [liveRef: [endpoint:[192.X.X.X:XXXXX](local),objID:[-6a665beb:15a2c8b9419:-7fff, 3180474504933847586]]]
Controller 서버에서 Test Plan 실행
2-1. Worker 서버들을 설정하는 두가지 방법 a) Worker 서버들을 METER_HOME/bin/jmeter.properties 파일에 'remote_hosts' 표기
remote_hosts=172.0.0.1, 172.0.0.2...
b) '-R' 옵션으로 CLI 직접 표기
-R 172.0.0.1, 172.0.0.2
2-2. 테스트 실행
'-r' : 2-1번의 a 방식으로 jmeter.properties 설정한 주소들을 그대로 사용하는 경우
java.lang.OutOfMemoryError: Java heap space 트러블 슈팅
-> 기본 heap 사이즈 설정이 1GB로 되어있기 때문에JVM_ARGS설정을 통해 조정 가능
Increase the Java Heap size. By default JMeter runs with a heap of 1 GB, this might not be enough for your test and depends on your test plan and number of threads you want to run
TPS를 높이기 위해서 Thread Group 설정을 여러번 바꿨으나 계속 비슷하게 나오는 경우가 있었다. https://clarkshim.tistory.com/169해당 블로그를 확인했을때 우리의 경우에는 '클라이언트 수가 너무 많다' 였던 것 같다.
결과를 기준으로 말하자면 Thread(users) 수를 높게 잡고(200정도) loop 수를 낮게(100) 설정했을때는 Troughput의 결과가 겨우 3000정도가 나왔다. Thread가 너무 많다보면 요청을 보내려는수많은 스레드들간의 경쟁으로 인해 오히려 처리시간이 길어질 수 있어서 문제가 된 듯 했다.
일단 JMeter의 서버 1대와 대상서버 1대로 최소한의 상황에서 진행했다.대상서버의 CPU가 85% 내외정도로 도달하는 수치를 찾기위해 이전보다thread 수는 50정도로 낮추고loop 수를 대폭늘려 1000정도로 설정했다. 그리고ramp-up period 설정을 10으로 설정해서 스레드가 10초 간격으로 하나씩 늘어나며 테스트하도록 설정했다(ramp-up period는 총실행시간에 포함되지 않는다). 이렇게 한 결과 Throughput이 이전 결과의 2배는 더 높게 나왔다!!
대상서버의 성능을 테스트하기 위해서는 적절한 thread, loop, ramp-up period 설정을 찾는게 관건인 듯 하다.
Artillery는 써봤지만 JMeter를 이렇게 다뤄본건 처음인것 같다. 요즘 좋은 성능테스트 툴도 많이 나오던데 JMeter는 문서도 친절하지 않은 편에 Distributed Testing 환경도 직접 구축해야하는게 너무 번거로웠다. 혹시나 저처럼 JMeter를 사용해야하는 분들께 조금이라도 도움이 되기를 바랍니다.
댓글