성능지표로 설정된 HTTP API의 동시 접속자 수 테스트를 수행할 때, 많은 고민이 생깁니다.
특히 400명 이상의 사용자가 1시간 동안 에러 없이 조회 요청을 처리하는 조건
요청 주기를 어떻게 설정해야 현실적인 결과가 나오는지 궁금할 수밖에 없습니다.
JMeter를 이용해 성능(부하) 테스트 시 가장 흔히 하는 고민인 "요청 주기(request rate) 설정"을 명확히 정리해 드리겠습니다.
동시 접속자와 요청 주기의 의미
흔히 '동시 접속자 400명'이라고 하면, 단순히 사용자 400명이 동시에 서비스를 이용하는 것으로 생각할 수 있습니다.
하지만 실제 서비스 환경에서 사람은 1초 내외의 간격으로 화면을 클릭하고 조회 요청을 합니다.
즉, 현실적인 요청 간격(thinking time)을 반영하지 않으면, JMeter가 기본적으로 ms 단위로 너무 빠르게 요청을 보내 실제 상황과는 동떨어진 결과가 나옵니다.
Think Time 설정 가이드
Think Time이란?
Think Time이란 사용자가 실제 서비스를 이용할 때, 두 개 이상의 요청(화면 전환 등) 사이에 발생하는 자연스러운 대기 시간을 의미합니다. 이 시간은 현실적인 사용자 행동을 정확히 반영하여 성능 테스트의 신뢰성을 높이는 데 매우 중요합니다.
Think Time 설정 목적
Think Time 설정은 특히 유저 기반의 동시 접속 시 발생 가능한 장애를 방지하기 위한 목적으로, 서비스 특성에 따라 적절한 호출 간격을 설정하는 데에 있습니다.
서비스 유형별 권장 Think Time
| 엑셀 문서 다운로드 | 약 1분 |
| 웹 페이지 조회 (일반적) | 3초 ~ 10초 |
| 앱 화면 조회 (일반적) | 0.5초 ~ 3초 |
API 테스트 시 고려사항
Think Time 적용 예외
단위 API 레벨의 성능 테스트에서는 보통 Think Time을 적용하지 않습니다. 왜냐하면 API 호출은 일반적으로 서비스 간의 자동화된 호출로 이루어지기 때문에 사용자의 생각 시간이 존재하지 않기 때문입니다. 이 경우에는 TPS(초당 처리 건수) 지표로 성능을 평가하는 것이 더 적합합니다.
Pacing Time 사용
호출 속도가 빠른 API와 같이 각 API 호출 간격을 일정하게 유지해야 할 경우, JMeter에서는 Think Time 대신 Pacing Time을 설정하여 사용합니다. 이는 API 간 호출 속도를 균일하게 유지하기 위한 방법입니다.
정리하자면, 웹이나 앱과 같이 사용자의 실제 행동을 시뮬레이션하는 경우 Think Time을 설정하고, API 간 호출 간격을 일정하게 유지할 때는 Pacing Time을 적용하는 것이 효과적인 성능 테스트 방법입니다.
현실적인 요청 주기 설정 방법
추천 설정
- Thread 수(동시 사용자 수): 400명
- Ramp-up 시간(사용자가 점진적으로 증가하는 시간): 60~120초
- 요청 주기(Constant Timer): 1000ms (1초) 혹은 현실적인 스마트폰 화면 클릭 간격(800~1200ms)
- 테스트 지속 시간(Duration): 3600초 (1시간)
이 설정은 사용자가 실제로 스마트폰 앱에서 조회 버튼을 누르는 간격을 시뮬레이션 한 것으로, 초당 400건의 요청을 처리하는 현실적인 테스트가 됩니다.
고객 환경에 따른 추가 고려사항 (클라우드 환경 과금 주의)
클라우드 환경에서는 요청 수와 데이터 전송량에 따라 비용이 발생합니다. 그러다 보니 테스트 중 과도한 요청 수는 예산 초과 문제로 이어질 수 있습니다.
따라서 아래의 내용을 고려하여 과금을 최소화하면서도 현실적인 테스트를 수행하는 것이 중요합니다.
- 과금 주의: 무리한 ms 단위 요청은 불필요한 과금을 발생시킬 수 있습니다.
현실적인 요청 주기(1초 내외)로 설정하면 실제 사용자 환경을 잘 반영하면서 비용도 관리할 수 있습니다.
- TPS 계산을 통해 적정 요청 주기 설정: 실제 환경과 유사한 TPS(초당 요청 수)를 고려해 요청 간격을 설정하세요.
예를 들어, 초당 400건의 요청이면 현실적인 트래픽 시나리오를 반영한 합리적 테스트가 가능합니다.
최종 권장 JMeter 설정 요약
- Number of Threads(사용자 수): 400
- Ramp-Up Period: 120초 (점진적 부하 증가)
- Constant Timer: 1000ms (혹은 Uniform Random Timer 800~1200ms)
- Duration: 3600초 (1시간)
이렇게 하면 정부과제 평가 시 현실적이며, 정확한 성능 테스트 결과를 얻을 수 있습니다.
과도한 과금을 피하면서도 심사위원과 고객 모두를 만족시키는 현실적인 테스트 결과를 확보할 수 있습니다.
'부하_성능테스트(load_performance)' 카테고리의 다른 글
| AWS 로드 밸런싱 확인/모니터링 방법 (0) | 2024.04.03 |
|---|---|
| AWS 로드 밸런싱 테스트 방법 알아보니... (0) | 2024.04.02 |
| WebPageTest를 사용하여 특정 웹사이트에 로그인한 후 속도 측정을 수행 하는 방법을 알아보니.. (0) | 2023.09.07 |
| Google PageSpeed Insights 로컬 서버 구축 해서 주기적으로 웹사이트 속도 측정하는 방법 알아보니.... (0) | 2023.09.06 |
| 무료 서비스/체감 속도 모니터링 방법 알아보니... (0) | 2023.09.05 |
