Skip to content

Latest commit

 

History

History
56 lines (41 loc) · 2.55 KB

File metadata and controls

56 lines (41 loc) · 2.55 KB

DB 풀 스캔 성능 테스트 케이스 및 결과 요약

이 문서는 URL 리다이렉션 서비스의 초기 아키텍처인 'DB 풀 스캔' 방식의 성능 한계를 파악하기 위해 수행된 테스트의 상세 결과입니다.

🟢 테스트 환경 및 설정

항목 내용
테스트 목표 주어진 부하에서 응답 시간 200ms 미만 및 성공률 98% 이상을 달성하는지 검증
테스트 도구 k6 (constant-arrival-rate executor 사용)
테스트 대상 localhost:8080에서 실행 중인 스프링 애플리케이션
테스트 데이터 100만 건의 URL이 저장된 MySQL 데이터베이스
테스트 부하 시나리오 1: 50 TPS (초당 50회 요청) <br> 시나리오 2: 100 TPS (초당 100회 요청)
테스트 기간 각 시나리오별 5분

🟢 k6 테스트 설정값 상세

설정 항목 시나리오 1 (50 TPS) 시나리오 2 (100 TPS)
rate 50 100
timeUnit '1s' '1s'
duration '5m' '5m'
preAllocatedVUs 100 100
maxVUs 10000 10000
thresholds 'success_rate': ['rate>0.98'],<br> 'http_req_failed': ['rate<0.01'] 'success_rate': ['rate>0.98'],<br> 'http_req_failed': ['rate<0.01']
TIME_THRESHOLD 200 (ms) 200 (ms)

🟢 실제 테스트 결과 및 결론

시나리오 1: 50 TPS 부하 (PASS)

지표 분석
성공률 98.40% 목표인 98%를 초과 달성하며 성공.
총 요청 수 15,000건 -
평균 응답 시간 51.14ms 목표(200ms)보다 훨씬 빠르게 처리.
p95 응답 시간 88.18ms 요청의 95%가 100ms 이내에 처리.

시나리오 2: 100 TPS 부하 (FAIL)

지표 분석
성공률 0.09% 목표인 98%에 크게 미달하며 실패.
총 요청 수 29,896건 -
평균 응답 시간 1.19s 목표(200ms)의 약 6배에 달하는 심각한 지연 발생.
p95 응답 시간 1.93s 대부분의 요청이 2초 가까이 소요되며 사용자 경험에 치명적.

최종 결론

현재의 'DB 풀 스캔' 방식은 초당 50건의 요청은 처리할 수 있지만, 부하가 100 TPS로 2배 증가했을 때 응답 시간이 1초 이상으로 폭증하며 시스템이 정상적으로 작동하지 못하는 병목 현상이 발생합니다.