상품 검색 API에서 캐싱 미처리와 캐싱 처리 TPS, 응답 시간 비교
[ 목차 ]
성능이 좋은지 파악하기위한 지표
- Users : 동시에 사용할 수 있는 유저 수
- TPS : 초당 몇개의 테스트를 처리할 수 있는지(Test per second)
- Time : 얼마나 빠른지
- 포화지점 : 초당 처리할 수 있는 처리량 수가 한계에 도달했고, 이후 사용자가 증가하면 Latency가 증가한다는 것을 의미한다. = 해당서버가 감당할 수 있는 한계지점을 의미
- ramp up: 시스템에 갑자기 높은 부하를 주면 병목 현상이 발생할 수 있어 부하를 점진적으로 증가시키면서 테스트하는 과정
1. 준비
먼저 상품 검색 api의 성능 테스트를 위해 상품 테이블에 더미 데이터 10만개를 생성했다.
그 다음으로 nGrinder를 설치 및 실행해주었다.
처음에는 직접 controller를 다운받아 실행했었는데, 스크립트에서 jdk 버전 불일치 문제가 발생해서 환경변수를 jdk 11로 변경해주는 등 갖은 시도를 했지만 반복되는 에러 끝에 결국 docker에서 nGrinder를 실행했다.
진작 이렇게 할 걸
비교 기준
성능 테스트도 처음이고 당연히 nGrinder도 처음이라 무슨 기준으로 어떻게 테스트를 해야할지 몰라 일단 vuser를 높여가면서 테스트를 진행하고 TPS, 평균 응답 시간을 비교해보았다.
(300 이상부터 컴퓨터가 멈춰버리는 관계로 소박한(?) 유저 수로 테스트 했음을 참고...)
1. vuser가 10명일 경우 캐싱 적용, 미적용 비교
2. vuser가 50명일 경우 캐싱 적용, 미적용 비교
3. vuser가 100명일 경우 캐싱 적용, 미적용 비교
2. 비교
1. VUSER=10
1) 캐싱X
- TPS: 15.3
- Mean Test Time: 558.90 ms
2) 캐싱O
- TPS: 361.9
- Mean Test Time: 9.30 ms
| 테스트 조건 | TPS(초당 트랜잭션) | 평균 응답 시간(ms) |
|---|---|---|
| 캐싱 미적용 | 15.3 | 558.90 |
| 캐싱 적용 | 361.9 | 9.30 |
2. VUSER=50
1) 캐싱X
- TPS: 14.7
- Mean Test Time: 3,211 ms
2) 캐싱O
- TPS: 429.9
- Mean Test Time: 93 ms
| 테스트 조건 | TPS(초당 트랜잭션) | 평균 응답 시간(ms) |
|---|---|---|
| 캐싱 미적용 | 14.7 | 3,211 |
| 캐싱 적용 | 429.9 | 93 |
3. VUSER=100
1) 캐싱 X
- TPS: 14.9
- Mean Test Time: 6,213 ms
2) 캐싱O
- TPS: 333.2
- Mean Test Time: 286.94 ms
| 테스트 조건 | TPS(초당 트랜잭션) | 평균 응답 시간(ms) |
|---|---|---|
| 캐싱 미적용 | 14.9 | 6,213 |
| 캐싱 적용 | 333.2 | 286.94 |
3. 최종 결과
캐싱을 적용했을 때 TPS 그래프가 좀 튀는 모습을 보이는데 원인은 알 수 없었다... 튜터님께 여쭤봤지만 통상적인 TPS와 평균 시간에 더 중점을 두고 비교하는 것이 맞고 그래프는 시간을 늘려서 측정하면 더 안정적으로 보일 것이니 상관없다고 하셨다.
캐싱을 적용한 경우가 적용하지 않은 경우에 비해 모두 TPS가 크게 증가하고 평균 응답 시간은 감소하는 것을 볼 수 있었다. 따라서 대규모 트래픽 처리 시 캐싱 적용이 시스템 성능 향상에 효과적인 것을 알 수 있다.