캐싱 성능 테스트

분석

결과를 보면, 공연 목록을 10,000개로 늘렸을 때의 테스트 결과가 다음과 같습니다:

---

1. 주요 데이터

• 로그인 (POST)
  • Total requests: 626
  • Response time (Avg): 380ms
  • 90th percentile: 749ms
• 공연 조회 (GET, V1)
  • Total requests: 620
  • Response time (Avg): 315ms
  • 90th percentile: 513ms
• 공연 조회 V2 (GET, V2)
  • Total requests: 613
  • Response time (Avg): 110ms
  • 90th percentile: 57ms

---

2. 분석

1. 로그인 API

   • 평균 응답 시간(380ms)이 다른 API들에 비해 길며, 이는 데이터베이스와의 인증 처리 및 JWT 토큰 생성 과정이 포함되기 때문입니다.
   • 최대 응답 시간 (4,465ms): 트래픽이 몰리는 순간에 병목 현상이 발생했을 가능성.
   • 그래도 에러율이 0%로 안정적으로 동작.

2. 공연 조회 (V1)

   • 평균 응답 시간 (315ms): DB를 직접 조회하는 V1은 데이터가 많아질수록 응답 시간이 증가합니다.
   • 90th Percentile (513ms): 대부분의 요청이 500ms 이내에 처리되지만, 데이터베이스의 병목이 발생할 가능성이 있음.
   • 데이터 10,000개에 대해 직접 DB를 조회했음에도 큰 에러 없이 동작.

3. 공연 조회 V2

   • 평균 응답 시간 (110ms): Redis 캐싱을 활용한 V2는 데이터 양이 많아져도 성능이 크게 저하되지 않음.
   • 90th Percentile (57ms): 대부분의 요청이 57ms 이내에 처리, 빠르고 일관된 응답 속도.
   • Redis의 캐싱 효과로, 데이터베이스에 비해 훨씬 효율적인 성능을 보여줌.

---

3. 비교

지표	공연 조회 V1	공연 조회 V2	차이
Avg Resp Time	315ms	110ms	65% 향상
90th Percentile	513ms	57ms	88.9% 향상
Max Resp Time	4,425ms	4,379ms	거의 동일

• 평균 응답 시간: V2가 V1보다 약 65% 빠름.
• 90th Percentile: V2는 대부분의 요청을 57ms 이내에 처리하며, V1보다 약 89% 더 일관성 있는 성능을 제공.
• 최대 응답 시간: 두 API 모두 트래픽이 몰리는 순간에 비슷한 병목 현상이 발생.

---

4. 결론

• Redis 캐싱을 활용한 V2가 데이터 양이 많아질수록 성능 차이를 더 크게 보여줌.
• V2는 데이터베이스를 직접 조회하지 않고 캐싱된 데이터를 조회하기 때문에 요청당 처리 시간이 크게 단축.
• 추천:
  1. V2를 기본 API로 사용하고, V1은 백업/참고용으로 유지.
  2. Redis의 캐싱 적중률(Cache Hit Rate)을 모니터링하여 최적화 방안을 추가 검토.
  3. 로그인 API의 병목 현상을 개선하기 위해 JWT 토큰 생성 로직 최적화 또는 Redis 기반 토큰 캐싱 고려.

---

추가적인 분석이나 개선이 필요하다면 알려주세요! 😊