반응형
Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 |
Tags
- C언어
- 연습문제
- 코드트리
- 디프만
- 디프만16기
- 코드 트리
- 코딩 테스트
- 코딩
- pub.dev
- flutter
- nGrinder
- 자료구조
- dip
- 부하 테스트
- AOP
- c
- java
- depromeet
- Sharding
- Redis
- 운영체제
- OAuth
- Spring
- Kotlin
- kakao
- Kafka
- Scaffold
- Oidc
- exception
- 코딩테스트
Archives
- Today
- Total
Nick Dev
[Outstagram] Cache 유무에 따른 성능 비교해보기 본문
반응형
게시물 관련 정보들을 캐시했을 때와 하지 않았을 때의 성능(응답속도)을 비교해보자!!
게시물 조회 로직에 캐시를 적용해야하는 이유
유저가 게시물 단건 조회 시 아래와 같이 많은 정보를 모아서 리턴한다.
- 게시물 정보
- 이미지 정보
- 게시물의 댓글 정보
- 게시물 작성자 유저 정보
이 정보들을 모두 DB에 질의해서 모아서 게시물 종합 정보를 리턴한다.
문제점
위 경우,
posts/100
으로 게시물을 하나 조회하게 되면 DB에 최소 4번의 쿼리를 날려야 된다.SNS 도메인 특성 상, WRITE보단 READ의 비중이 훨씬 크기 때문에 READ의 성능을 개선할 필요가 있다.
그래서 각 정보들을 Redis에 캐시해놓고 캐시된 데이터들을 조합해서 리턴하도록 코드를 리팩토링했다.
- 각각 따로 캐시해놓고 조합해서 리턴하는 이유는 조합된 데이터를 캐시해놓는다면 댓글이나, 좋아요 개수, 게시물 수정 등 변경이 일어날 때마다 캐시를 내렸다가 다시 올려야되기 때문에 오히려 오버헤드가 발생할 수 있기 때문이다.
🔨 세팅
nGrinder를 통해 트래픽 부어보기
vuser 301명이 각각 30분동안 계속 게시물 49,000개 중 랜덤으로 200개씩 조회하는 상황
캐시가 있을 때와 없을 때를 비교해보자!
✅ 캐시 없는 경우, 부하 테스트 결과
✅ 캐시 있는 경우, 부하 테스트 결과
⭐ 비교 결과
캐시를 도입했을 때, 성능이 70% 이상 개선되었다고 볼 수 있다.
로그를 살펴본 결과, 캐시가 없을 때는 조회 api가 500ms까지 소요될 때가 있었지만, 캐시가 있을 때는 100ms 넘어가는 경우가 거의 없었다.
30분간 수행한 테스트의 개수도 캐시가 있을 때, 3배 가까이 소화했다.
테스트당 api를 203개씩 호출하는데 캐시가 있을 때가 없을 때보다 테스트를 34,602개 더 수행했다. 즉, 캐시가 있을 때, 7,024,206개의 api를 더 감당했다는 것이다.
조회 비중이 많은 서비스일 수록 캐시 유무에 따른 성능 차이가 극대화되는 것 같다.
반응형
'Outstagram' 카테고리의 다른 글
[Outsagram] nGrinder & pinpoint로 병목 지점 파악 후, sharding을 통해 성능 개선한 경험 (1) | 2024.12.12 |
---|---|
[Outstagram] kafka 메시지 큐를 활용해 비동기 메시지 전송을 도입한 이유 (0) | 2024.12.12 |
[Outstagram] nGrinder를 활용한 부하 테스트 후 성능 튜닝 과정 (0) | 2024.12.12 |
[Outstagram] Redis에서도 동시성 이슈가 발생한다고...? (lua script 적용기) (0) | 2024.12.12 |
[Outstagram] 템플릿 메서드 패턴을 실제 프로젝트에 적용해보기 (0) | 2024.12.12 |