[Docs] 견적서 전체 및 상세 조회 API 성능 테스트 리포트

[rimeir]

📌 테스트 개요

항목	내용
목적	견적서 API 성능 측정 및 개선 사항 파악
대상 API	GET /api/v1/estimates (전체 조회) GET /api/v1/estimates/{id} (상세 조회)
데이터 조건	약 10,000건의 견적서
요청 수	각 테스트당 1000회 (Number of Threads: 100, Ramp-up period: 1, Loop Count: 10)
테스트 도구	Apache JMeter 5.6.3
환경	로컬 개발 환경 (Spring Boot + MySQL), 캐시 미적용 상태

📊 테스트 결과 요약

견적서 전체 조회 API (GET /api/v1/estimates)

실행 회차	평균 응답(ms)	최대(ms)	최소(ms)	표준편차(ms)	처리량(req/sec)	비고
1차	1731	4232	121	717.59	41.27	전체 데이터 응답 (1.5MB)
2차	1196	3401	92	602.33	56.26	동일 조건 반복 테스트

평균 응답 시간 30.9% 감소, 처리량 36% 향상

• 첫 실행보다 두 번째 실행에서 응답 시간이 크게 줄어든 것은 JVM 최적화(JIT) 또는 DB의 내부 캐시 효과일 가능성이 높습니다. ( Cold Start → Warm State)
• 전체 견적서 데이터를 한 번에 응답하는 구조는 최대 응답 시간이 3~4초까지 증가하는 원인이므로, Pageable 기반의 페이징 처리로 분할 응답이 필요합니다.

견적서 상세 조회 API (GET /api/v1/estimates/{id})

실행 회차	평균 응답(ms)	최대(ms)	최소(ms)	표준편차(ms)	처리량(req/sec)	비고
1차	103	912	9	127.07	472.14	단일 견적서 반복 조회
2차	54	618	8	79.28	641.44	동일 조건 반복 테스트

평균 응답 시간 47% 감소, 처리량 36% 증가

• 견적서 상세 조회 반복 요청 시에도 성능이 개선되는 현상이 나타났습니다. (Cold Start → Warm State)

⚠️ 분석 및 개선 방향

문제점	분석	개선 방향
전체 조회 응답 크기 약 1.5MB	페이징 미적용	Pageable 적용 필요
응답 편차 큼 (표준편차 600~700ms)	응답 일관성 부족	캐시 적용, 쿼리 최적화 필요
최대 응답 시간 3~4초	일부 요청에서 병목 현상 발생 가능성	GC 일시 정지, 쿼리 최적화, fetch 전략 확인 필요
처리량 편차 존재	트래픽 증가 시 처리량 불안정	ThreadPool, DB 커넥션 풀 설정 최적화 고려

🔧 개선 사항

• GET /api/v1/estimates에 페이징 처리 (Pageable) 적용
• @Cacheable을 통한 상세 조회 Redis 캐시 전략 적용
• 연관된 member 조회 시 N+1 문제 방지를 위해 @EntityGraph 또는 JOIN FETCH 사용
• JMeter를 스크립트 기반으로 자동 실행하고 응답 시간/처리량 통계를 자동 수집하는 테스트 체계 마련

---

📅 작성일: 2025-06-03
🧑‍💻 작성자: @rimeir