지난 주의 인기 프로젝트 조회 성능 개선

[uijin-j]

🎫 관련 이슈

Resolves #257

✅ 구현 내용

• 캐시 적용
• 테스트 코드 수정 및 추가
• 부하 테스트

💬 코멘트

플로우 차트

성능 테스트

💬 성능 테스트는 지난 주 좋아요 생성 수가 약 50,000개(5 만개)이고, 초당 약 10개 ~ 40개의 인기 프로젝트 조회 요청을 했을 때로 가정하고 진행했습니다! 성능 테스트 툴은 Artillery를 사용했습니다:)

❗️ 처음에는 지난 주 좋아요 생성 수가 약 5,000개인 경우로 성능 테스트를 진행했는데, 데이터가 적어서 그런지 캐시를 쓰는 것보다 오히려 안쓰는 것이 더 성능이 좋더라구요! 그런데 좋아요 생성 수가 늘어날수록 조인 연산 등 쿼리가 복잡해져 기하급수적으로 느려지는 것 같습니다.. 주별로 좋아요 수를 미리 카운팅해도 성능 향상이 될 것 같네요😊 다음에 도전..!
그리고 일주일동안 생성된 좋아 수가 50만개 일때는 초당 100개 이상의 time out이 나더라구요😅 해당 경우는 너무 트래픽이 극단적이라 오히려 비교가 정확하지 않을 것 같아서 5만개로 했습니다!

• 10초 단위로 요청 트래픽을 증가 → 감소하며 부하 테스트를 진행

• 캐시를 사용하지 않는 경우, 99%의 사용자가 1초(1,000ms) 내외로 응답을 받음

• 캐시를 사용한 경우, 99%의 사용자가 40ms 내외로 응답을 받음
• 첫 요청의 경우 캐시 미스로 DB에서 직접 데이터를 가져오기 때문에 Max 응답 시간이 약 1초인 것을 확인할 수 있음
• 캐시의 만료 기간은 해당 주의 마지막 날(일요일) 자정까지 유효하도록 계산하여 설정 (매주 갱신되는 데이터이기 때문)

💡 결론, 캐시 도입으로 인해 99%의 요청이 25배 더 빠른 응답 속도를 얻을 수 있습니다!

[github-actions]

📝 Jacoco Test Coverage

Overall Project	66.55% -1.07%	❌
Files changed	69.4%	❌

File	Coverage
ProjectSummary.java	100%	🍏
ProjectBannerResponse.java	100%	🍏
QuerydslPopularProjectRepository.java	100%	🍏
RedisConfig.java	100%	🍏
ProjectService.java	95.3%	🍏
DateUtils.java	73.17% -26.83%	❌
PopularProjectCacheService.java	67.19% -32.81%	❌
ProjectRepositoryCustomImpl.java	27.44% -10.4%	❌
ProjectController.java	0% -5.8%	❌