서론
이전 글에서 APACHE JMeter관련해서 테스트 측정 방법들을 공유했습니다.
https://jaymon0327.tistory.com/6
APACHE JMeter를 통한 부하테스트 및 보고서 작성
부하 테스트를 위한 도구들 구글링을 통해 찾아본 테스트 도구로는 nGrinder, JMeter, k6 등이 있었습니다. 처음엔 네이버에서 제공하는 오픈소스인 nGrinder를 사용하려 했지만 JDK 11 까지만 지원해서 J
jaymon0327.tistory.com
해당 측정방법으로 기존 프로젝트와 개선된 프로젝트를 테스트했고, 이번 포스팅에선 그 결과에 초점을 맞추어 저의 경험을 공유하고자 합니다.
* 측정 도중에 JMeter의 JVM 힙메모리 문제(OutOfMemory Exception)의 대한 해결 방법도 있습니다.
쓰레드 그룹 설정
쓰레드 그룹 설정에는 동시접속자 수 100명정도가 이용할때의 성능을 측정하는 것이 목표였습니다.
이전 글에서 설명드린 것처럼 1초에 100명이 접속하는 것을 30번 반복하는 것으로 설정을 하고 각 API들을 테스트 했는데요.
프로젝트의 API마다 3,000건씩 12,000건의 요청을 테스트 했습니다.
1000개의 쓰레드로 측정하는 것이 애플리케이션의 성능을 더 직관적으로 확인할 수 있다고 하는데요.
저의 경우에는 기존의 프로젝트와 현재 프로젝트의 성능 비교가 우선이었고, 레거시 프로젝트가 감당할 수 있을만큼만 조정해야 일관성 있는 테스트가 가능하기 때문에 계속 조정해보며 최적의 값을 찾아냈습니다.
이처럼 쓰레드 그룹 설정을 변경하는 것은 계속 조정해보며 일관성 있는 값을 얻어낼 수 있는 설정값으로 측정해야 합니다.
테스트 결과 분석
우선 JMeter 툴에서 제공하는 측정에는 크게 6가지가 있습니다.
측정 테스트 결과 사진을 보면서 6가지에 대해 설명 드리겠습니다.
1. Apdex (애플리케이션 성능 지수)
Apdex 점수는 응답 시간을 기반으로 사용자의 만족도를 나타냅니다.
- 레거시 프로젝트: Apdex 점수가 매우 변동적이었으며, 0.002처럼 낮은 점수가 있어 사용자 경험이 매우 불만족스러웠음을 나타냅니다.
- 현재 프로젝트: Apdex 점수가 일관되게 0.974 이상으로, 대부분의 요청이 만족스러운 사용자 경험 범위 안에 있음을 보여줍니다.
2. 처리량 (초당 트랜잭션 TPS):
처리량은 애플리케이션이 1초 동안 처리하는 트랜잭션 수를 측정하며, 애플리케이션의 부하 처리 능력을 직접적으로 나타냅니다.
- 레거시 프로젝트: 초당 평균 약 13건의 트랜잭션을 처리하였습니다.
- 현재 프로젝트: 초당 평균 107건으로 대폭 향상되어 훨씬 더 많은 트랜잭션을 효과적으로 처리할 수 있음을 나타냅니다.
3. 평균 응답 시간 (ms):
평균 응답 시간은 애플리케이션이 요청에 응답하는 데 걸리는 시간을 측정하며 사용자 경험에 있어 매우 중요한 요소입니다.
- 레거시 프로젝트: 평균 응답 시간이 2007.41 ms로, 일반적으로 받아들여지는 2초 기준을 넘었습니다.
- 현재 프로젝트: 평균 151.66 ms로 크게 개선되었으며, 레거시 프로젝트에 비해 현저히 빠른 응답 시간을 나타내 사용자 경험이 향상되었습니다.
4. 최대 응답 시간 (ms):
테스트 동안 경험된 최악의 경우의 응답 시간입니다.
- 레거시 프로젝트: 기록된 가장 긴 응답 시간이 13,184 ms로, 사용자 경험에 치명적입니다.
- 현재 프로젝트: 최대 응답 시간이 1,334 ms로 줄어들어 최악의 경우에도 이전보다 훨씬 빠르게 반응함을 보여줍니다.
5. 네트워크 처리량 (KB/sec):
네트워크 처리량은 데이터 전송률을 나타내며 네트워크 이용 효율성을 나타내는 지표입니다.
- 레거시 프로젝트: 수신 데이터가 약 69583.36 KB/sec, 송신 데이터가 약 14.70 KB/sec였습니다.
- 현재 프로젝트: 수신 데이터가 1539.10 KB/sec로 개선되고, 송신 데이터가 91627.29 KB/sec로 급격히 증가하였습니다. 이는 네트워크 효율성 및 데이터 처리 능력이 대폭 개선되었음을 보여줍니다.
이렇게 기존 프로젝트와 개선된 프로젝트를 비교해보았는데요.
애플리케이션 성능에 중요한 지표대로 순서를 매기자면
평균 응답 시간, 최대 응답시간 > TPS > 네트워크 처리량 > Apdex 라고 할 수 있습니다.
추가로 오류발생률도 제공을 해주는데요. 0%가 아니라면 테스트시에 문제가 발생했을수도 있으므로 다시 한번 테스트를 시도해보는 것을 추천드리겠습니다.
저의 경우에는 해당 수치들을 중요한 지표 순서대로 표로 정리해서 포트폴리오에 추가했습니다.
| 지표 | 레거시 | 현재 | 향상된 비율 (%) |
| 평균 응답시간 (ms) | 2007ms | 151ms | 92.48% 감소 |
| 최대 응답시간 (ms) | 13,184ms | 1,334ms | 89.88% 감소 |
| 처리량 (초당 트랜잭션) | 13건 | 107건 | 723.08% 향상 |
| 네트워크 처리량 (KB/sec) | 69,583KB | 1,539KB | 97.79% 감소 |
| Apdex | 0.002 | 0.974 | 48,600% 향상 |
JMeter의 HTML 보고서를 확인해보면 눈으로 확인할 수 있는 그래프를 제공하는데요.
성능 비교를 위해 더 직관적으로 확인이 가능해 좋은 기능이라고 생각합니다.
부하테스트 진행 과정에서의 문제
개선된 프로젝트를 부하테스트 할때는 쓰레드 그룹 설정과 관련없이 테스트가 일관성있게 동작했으나 레거시 프로젝트는 작동하던 도중에 쓰레드가 멈춰버리는 현상이 자주 발생해 테스트를 측정하기가 어려웠습니다.
Uncaught Exception java.lang.OutOfMemoryError: Java heap space in thread Thread[#60,쓰레드 그룹 1-3,6,main]. See log file for details.
OutOfMemory Exception은 Java의 Heap 메모리가 부족하다는 뜻으로 강제로 쓰레드가 중지되게 됩니다.
이를 해결하기 위한 방법이 2가지가 있습니다.
1. 힙 메모리 크기 조정
JVM 시작 시 할당된 힙 메모리 크기(-Xms로 시작 크기 설정, -Xmx로 최대 크기 설정)를 조정하여 이 문제를 해결할 수 있습니다.
vi /opt/homebrew/bin/jmeter위 명령어를 통해 vim 편집기를 열고 안에 있는 코드에 힙 메모리 용량을 늘려주면 됩니다.
(저는 Mac 이용자이기때문에 윈도우 이용자는 설치한 폴더로 이동해서 bat 파일을 설정해주세요)
export JAVA_OPTS="-Xms1024m -Xmx2048m"
/opt/homebrew/Cellar/jmeter/5.6.3/libexec/bin/jmeter저의 경우에는 시작 메모리(-Xms 1024)/최대 메모리(-Xmx 2048) 으로 넉넉하게 늘려주었습니다.
cat /opt/homebrew/Cellar/jmeter/5.6.3/bin/jmeter제대로 설정됐는지 확인할때는 cat 명령어를 통해 스크립트를 조회해서 확인합니다.
2. CLI 환경으로 실행하기
이전 포스팅에서 설명했던 방법입니다. 힙 메모리를 늘리지 않고 CLI 환경으로만 실행해도 힙 메모리가 충분하다면 이것만으로 해결이 가능할 수가 있습니다.
터미널을 통해 /opt/homebrew/bin 폴더에 들어가줍니다. (jmeter가 위치한 폴더)
jmeter -Jjmeter.save.saveservice.output_format=csv -n -t /Users/jaymon/desktop/APACHE_JMeter/20240410_mi.jmx -l
/Users/jaymon/desktop/APACHE_JMeter/20240410_mi.csv -e -o
/Users/jaymon/desktop/APACHE_JMeter_Result/mi_0410/
위의 명령어 설정은 설정파일과 결과물을 저장할 파일(미리 만들어둔파일은 X), 그리고 웹보고서를 저장할 폴더(비어있어야함)을 지정합니다.
저 같은 경우는 결과물출력파일을 csv로 저장했기 때문에 output_format=csv 옵션을 부여했습니다.
jmeter -Jjmeter.save.saveservice.output_format=csv -n -t
[jmeter설정파일] -l [결과물을저장할파일] -e -o [웹보고서를저장할폴더]
이렇게 해서 실행하면 GUI로 실행했을 때보다 일관성 있는 결과물을 얻을 수 있고, 훨씬 빠르게 테스트가 종료되게 됩니다.
