JMeter와 함께하는 부하테스트,, 노트북이 버티지 못할까 조마조마한 마음으로 진행을 해보았습니다,,
다행이 docker 내부의 mysql이 CPU를 100% 넘기면서까지 노력해줘서 잘 마무리를 했습니다,,🌹
간단하게, JMeter 설치와 부하테스트 결과를 정리해 보겠습니다,,
기본 환경
- OS: Windows 11 Home
- Language: Java
- DB: MySQL, Redis
- IDE: IntelliJ
0. 사전 지식 🥸
기준 |
Spring MVC | Spring WebFlux |
처리 방식 | 동기/블로킹 | 비동기/논블로킹 |
서버 지원 | Tomcat (Servlet 기반) | Netty, Undertow, Tomcat 등 지원 |
성능 (대규모 트래픽) | 스레드 수에 따라 성능 제한 | 높은 동시성 처리 및 확장성 우수 |
디버깅 | 용이 | 어려움 |
주요 사용 사례 | 전통적인 웹 앱, 관리 시스템 | 실시간 데이터, 채팅, IoT, 스트리밍 서비스 |
1. JMeter 설치
The Apache JMeter™ application is open source software, a 100% pure Java application designed to load test functional behavior and measure performance.
It was originally designed for testing Web Applications but has since expanded to other test functions.
Apache JMeter™ 애플리케이션은 기능 동작을 로드하고 성능을 측정하도록 설계된 100% 순수 Java 애플리케이션인 오픈 소스 소프트웨어입니다.
원래 웹 애플리케이션을 테스트하기 위해 설계되었지만 이후 다른 테스트 기능으로 확장되었습니다.
⭐ JMeter는 순수 자바 애플리케이션으로, Java 8 문법을 내부적으로 사용하기 때문에 자바 8 버전 이상이 설치되어 있어야합니다.
저도 정리할 수 있지만,, 이미 잘 정리된 글이 있다면,, 공유하는 게 더 효율적이라고 생각합니다^,,^
저도 따라했는데, 성공했습니다 ^,,^
https://developer-jinnie.tistory.com/105
2. JMeter Plugin 설치
Transaction per Seconds와 Response Times Over Time을 함께 측정하기 위해 플러그인도 함께 설치합니다.
플러그인 설치 방법은 아래 블로그를 참조하시면 됩니다^,,^
https://blog.naver.com/ka28/222492575671
3. 테스트할 API 준비
저는 MVC와 WebFlux에 대해 크게 3가지씩 테스트 할 예정입니다.
* 단순 String을 반환하는 API
* RDB를 조회하는 API
* Cache를 활용한 API
Case | MVC | Webflux |
단순 String 반환 | 1 | 1 |
RDB 데이터 조회 | 3 | 3 |
Caching 활용 | 2 | 2 |
대략 결과는 Webflux가 MVC보다 빠르되, String → Caching → RDB 순으로 빠르지 않을까,, 라고 예상해 봅니다.
4. Jmeter 설정
Thread Groups
Test Plan 우클릭 → Add → Threads (Users) → Thread Group
* Numbers of Threads (users): 동시에 테스트를 수행할 가상의 사용자 수
* Ramp-up period (seconds): 모든 스레드(사용자)가 가동될 때까지 걸리는 시간(초), 부하를 점진적으로 증가시키고 싶을 때 사용
* Ramp-up Period ÷ Number of Threads = 각 스레드의 시작 간격
* Loop Count: 각 가상 사용자가 요청을 몇 번 반복할지 설정
Http Reqeust
Thread Group 우클릭 → Add → Sampler → Http Request
* Protocol, Server name or IP, Port Number, Http Request 입력
5. 테스트 결과 해석
Summary Report
Http Request 우클릭 → Add → Listener → Summary Report
* #Samples: 테스트 동안 발생한 HTTP 요청의 총 개수
* Average: 평균 응답 시간(ms)
* Min / Max: 최소/최대 응답 시간(ms)
* Std. Dev. (표준 편차): 응답 시간의 변동성
* Error %: 에러율
* Throughput: 초당 처리된 요청 수
* Received KB/sec / Sent KB/sec: 초당 수신/송신된 데이터 양, 서버와의 데이터 전송 효율성을 나타냄
* Avg. Bytes: 요청당 평균 전송된 데이터 크기
Transaction Per Second
초당 처리된 트랜잭션(요청)의 수
* TPS가 높으면 서버가 빠르게 요청을 처리한다는 의미
* 테스트 중 TPS가 급격히 하락하면 서버 과부하 가능성이 존재
Response Times Over Time
시간 흐름에 따른 응답 시간 변화
* 초기에는 빠르다가 부하가 누적될수록 응답 시간이 증가하는지 확인
* 스파이크(급격한 증가) 구간을 보면 병목 현상이나 과부하 시점을 파악할 수 있음
🍀 부하 테스트 전략
- Baseline 테스트: 적은 사용자 수로 정상 동작 확인
- 부하 증가 테스트: Ramp-up을 활용해 점진적 부하 증가
- 스트레스 테스트: Ramp-up 없이 대량의 사용자로 한계 테스트
- 안정성 테스트: 오랜 시간 동안 고정된 부하로 서비스 안정성 확인
6. 테스트 결과 정리
✅단순 String 반환
💡단순 String 반환 시, Summary Report 기준 Webflux가 Avg는 낮고, Throughput은 더 높음
✅RDB 조회
💡RDB 조회 시, Summary Report 기준 Webflux가 Avg는 낮고, Throughput은 더 높음
✅RDB 조회 및 Caching 활용
💡Caching 활용 시, Summary Report 기준 Avg, Throughput 모두 비슷
⭐캐시 처리 시 WebFlux의 이점이 미미한 이유:
Redis 자체가 매우 빠름 → 논블로킹 I/O의 효과가 뚜렷하게 나타나기 위해선 대기 시간이 길어야 함
+ 단순 RDB 조회 시, MySQL은 두뇌 풀 가동 모습,,🤖
📑
참고 자료
Chat GPT
https://developer-jinnie.tistory.com/105
https://jaehoney.tistory.com/224
https://blog.naver.com/ka28/222492575671
'MinimiProject > 아이돌 티켓팅 접속자 대기열 시스템' 카테고리의 다른 글
[대기열 시스템] R2DBC와 Custom Query (0) | 2025.01.31 |
---|---|
[대기열 시스템] Redis와 Replication (0) | 2025.01.28 |
[대기열 시스템] Docker Compose로 Grafana와 Prometheus로 모니터링 시스템 구축하기 (0) | 2025.01.26 |
[대기열 시스템] RedisTemplate, RedisHash, @Cacheable (1) | 2025.01.25 |
[대기열 시스템] HTTP load testing tool, Vegeta 설치(Window) (0) | 2025.01.21 |