이번 글이 이번 프로젝트의 성능 최적화 글 중 마지막이 될 것이다. db io가 발생하지 않는다면 어플리케이션의 성능은 극대화 된다. 하지만 Redis와 같은 캐시서버의 운영 비용은 만만치 않으니 신중하게 선택하자.
나의 경우 로컬 캐시인 카페인 캐시를 이용해 캐시를 운영했다. 사용한 이유는 러닝 커브가 매우 낮다는 점이 가장 크다. 또한 성능이 매우 우수하다고 한다.https://github.com/ben-manes/caffeine/wiki/Benchmarks
힘들었던 점
캐시를 적용했을 때 가장 힘들었던 것은 캐시에 대한 전략이 어려웠다. 일단 모든 조회 로직에 대해 캐시를 적용했기 때문에 캐시 삭제를 할 때 매우 까다로웠다. 연관 되어있는 데이터 (예를 들어 개인 프로필이 수정되면 커플 프로필에서 응답하는 데이터도 수정되어야 함)를 파악하기 어려워 캐시 삭제하는 부분에서 많은 오류를 겪었다. 캐시를 적용할 때 내가 적용한 캐시의 응답 데이터와 연관이 있는 수정, 생성, 삭제 작업에 대해 정확하게 인지하고 있는 것이 중요하다고 느껴졌다.
결과
DB CPU 사용량(마스터 59%, 슬레이브 68%)
WAS CPU 사용량 (75%)
최종 TPS(149/s)
결과는 예상했던대로 큰 성능 개선이 되었으며 주어진 자원을 최대한까지는 아니더라도 어느정도 효율적으로 이용하고 있는 것을 확인할 수 있다.
'프로젝트 > 고민' 카테고리의 다른 글
내가 작성하지 않은 코드를 개선해보자 (0) | 2023.12.24 |
---|---|
성능 최적화 (S3업로드 병렬 처리와 이미지 리사이징) (0) | 2023.12.09 |
성능 최적화 (스케일 업, 인덱스 튜닝) (1) | 2023.12.02 |
Ngrinder로 성능테스트 하기 (2) | 2023.11.23 |
코드의 품질 관리를 도움 받기: SonarCloud, CodeMetrics (0) | 2023.10.13 |