JMeter를 활용하여 Redis 캐시 테스트 분석

테스트 조건(1)

• users(동시 접속자 수) : 100
• Duration(테스트 실행 시간) : 10초
• Loop Count : 10
• 캐시 되지 않은 상점(storeId = 100)으로 V1(캐시 미적용)과 V2(캐시 적용)을 독립적으로 실행하여 성능 비교
• V2(캐시 적용)는 한 번의 요청 이후 Redis 캐시에 저장되어 사용됨.

결과 비교

➡️ V1 (캐시 미적용)

캐시 미적용

➡️ V2 (캐시 적용)

캐시 적용

요청	샘플 수	평군 응답 시간(ms)	최소(ms)	최대(ms)	표준 편차	처리량(ThrouhPut)
Get Store V1 (No Cache)	2000	6ms	3ms	63ms	2.21ms	73.3 req/sec

요청	샘플 수	평군 응답 시간(ms)	최소(ms)	최대(ms)	표준 편차	처리량(ThrouhPut)
Get Store V2 (With Redis Cache)	2000	1ms	0ms	9ms	0.86ms	81.6 req/sec

1. 평균 응답 시간 비교

• V1 (캐시 미사용): 평균 6ms
• V2 (캐시 사용): 평균 1ms
  • 약 6배 정도 성능 향상됨!
  • Redis 캐시가 적용된 이후 응답 시간이 1ms로 거의 즉각적인 응답을 보여줍니다.

2. 최대 응답 시간 비교

• V1: 최대 63ms
• V2: 최대 9ms
  • V1에서는 최대 63ms까지 응답 시간이 증가함
  • V2에서는 최대 응답 시간이 9ms 이하로 유지됨.
  • 고객이 체감하는 응답 속도의 일관성이 향상됨.

3. 처리량(Throughput) 비교

• V1 (No Cache): 73.3 requests/sec
• V2 (Redis Cache): 81.6 requests/sec
  • 약 11.3% 더 많은 요청을 처리 가능
  • 동시 접속자가 많아질수록 Redis 캐시가 부하를 효과적으로 줄여줍니다.

 4. 응답 시간 편차 (표준 편차)

• V1: 2.21ms
• V2: 0.86ms
  • V2에서 응답 시간 편차가 더 작음.
  • 이는 Redis 캐시 덕분에 응답 시간이 더 일정하게 유지됨을 의미.
  • V1은 DB 접근 부하로 인해 응답 시간 변동이 크지만 V2는 거의 일정함

---

테스트 조건(2) - Cache Miss -> Cache Hit 전략

• users(동시 접속자 수) : 200
• Duration(테스트 실행 시간) : 10초
• Loop Count : 10
• 캐시 되지 않은 상점(storeId = 200)으로 V1(캐시 미적용)과 V2(캐시 적용)을 독립적으로 실행하여 성능 비교
• V2(캐시 적용)는 한 번의 요청 이후 Redis 캐시에 저장되어 사용됨.

결과 비교

➡️ V1 (캐시 미적용)

캐시 미적용

➡️ V2 (캐시 적용)

캐시 적용

요청	샘플 수	평군 응답 시간(ms)	최소(ms)	최대(ms)	표준 편차	처리량(ThrouhPut)
Get Store V1 (No Cache)	4000	6ms	2ms	44ms	2.05ms	154.0 req/sec

요청	샘플 수	평군 응답 시간(ms)	최소(ms)	최대(ms)	표준 편차	처리량(ThrouhPut)
Get Store V2 (With Redis Cache)	4000	1ms	0ms	25ms	1.12ms	171.8 req/sec

1. 평균 응답 시간 비교

• V1 (캐시 미사용): 평균 6ms
• V2 (캐시 사용): 평균 1ms
  • 약 6배 정도 성능 향상됨!
  • Redis 캐시가 적용된 이후 응답 시간이 1ms로 거의 즉각적인 응답을 보여줍니다.

2. 최대 응답 시간 비교

• V1: 최대 44ms
• V2: 최대 25ms
  • V1에서는 최대 44ms까지 응답 시간이 증가함
  • V2에서는 최대 응답 시간이 25ms 이하로 유지됨.
  • 고객이 체감하는 응답 속도의 일관성이 향상됨.

3. 처리량(Throughput) 비교

• V1 (No Cache): 154.0 requests/sec
• V2 (Redis Cache): 171.8 requests/sec
  • 약 11.5% 더 많은 요청을 처리 가능
  • 동시 접속자가 많아질수록 Redis 캐시가 부하를 효과적으로 줄여줍니다.

 4. 응답 시간 편차 (표준 편차)

• V1: 2.05ms
• V2: 1.12ms
  • V2에서 응답 시간 편차가 더 작음.
  • 이는 Redis 캐시 덕분에 응답 시간이 더 일정하게 유지됨을 의미.
  • V1은 DB 접근 부하로 인해 응답 시간 변동이 크지만 V2는 거의 일정함

---

테스트 조건(3) - 시각적 자료 포함, Cache Hit 상태

• users(동시 접속자 수) : 1000
• Duration(테스트 실행 시간) : 10초
• Loop Count : 10
• 이번에는 캐시에 저장이 된 상태로 V1(캐시 미적용과), V2(캐시 적용)으로 확인을 해봤습니다.

결과 비교

➡️ V1 (캐시 미적용)

캐시 미적용

➡️ V2 (캐시 적용)

캐시 적용

요청	샘플 수	평군 응답 시간(ms)	최소(ms)	최대(ms)	표준 편차	처리량(ThrouhPut)
Get Store V1 (No Cache)	10000	934ms	4ms	5512ms	661.32 ms	501.1 req/sec

요청	샘플 수	평군 응답 시간(ms)	최소(ms)	최대(ms)	표준 편차	처리량(ThrouhPut)
Get Store V2 (With Redis Cache)	10000	1ms	0ms	25ms	1.28ms	998.8 req/sec

1. 평균 응답 시간 비교

• V1 (캐시 미사용): 평균 934ms
• V2 (캐시 사용): 평균 1ms
  • 약 934배 정도 성능 향상됨!

2. 최대 응답 시간 비교

• V1: 최대 5512ms
• V2: 최대 25ms
  • V1에서는 최대 5512ms까지 응답 시간이 증가함
  • V2에서는 최대 응답 시간이 25ms 이하로 유지됨.

3. 처리량(Throughput) 비교

• V1 (No Cache): 661.32 requests/sec 
• V2 (Redis Cache): 998.8 requests/sec
  • 약 1.5배 정도 향상
  • 여기서 알 수 있었던 것. 캐시를 사용하지 않으면 DB 부하가 일정 수준 이상 증가하면 TPS 변동이 커지는 현상이 발생합니다.
    즉 부하가 높아질 수록 성능이 불안정해짐.
  • 또 캐시를 사용하면 요청을 Redis 캐시에서 바로 처리하며 부하가 없으므로 성능이 일정하게 유지됨을 알 수 있었습니다.

 4. 응답 시간 편차 (표준 편차)

• V1: 661.32ms(매우 불안정한 상태)
• V2: 1.28ms (매우 안정적)

---