Backend/🌿Spring

[SpringBoot] Redis 캐싱을 통한 좋아요 조회 성능 비교

발달중인 망고 2024. 4. 8. 21:23

안녕하세요!😄

오늘은 저번 시간에 설정했던 Redis를 이용해서 조회성능이 어느 정도 향상되는지 알아보겠습니다.

Redis

 

 

가이드 & 환경

- Spring3.2.2 , Postman, Redis, EC2

- SpringBoot CacheCode

- 테스트할 DTO , List <독후감 Dto>

- 조회 성능 차이 계산

 

SpringBoot Cache Code

@Service
@RequiredArgsConstructor
public class LikesCachingServiceImpl implements LikesCachingService {

    private static final Logger logger = LoggerFactory.getLogger(LikesCachingServiceImpl.class);
    private final LikesRepository likesRepository;

    @Override
    @Cacheable(value = "likesCount", key = "#reviewId")
    public Long 좋아요캐시업데이트(Long reviewId) {
        logger.info(reviewId+"의 캐시가 업데이트 되었습니다.");
        return likesRepository.countByReviewId(reviewId);
    }

    @Override
    @CacheEvict(value = "likesCount", key = "#reviewId")
    public void 좋아요캐시무효화(Long reviewId) {
    logger.info(reviewId+"의 캐시가 삭제 되었습니다.");
    }
}

💡 이전 Count쿼리에 중간 Caching Service를 두어 구현하였습니다. 나중에 이벤트 기반으로 변경해 보면 좋을 것 같습니다.

 

Redis 조회 성능 테스트

테스트할 데이터 DTO

💡 데이터베이스에서 데이터가 가장 많이 조회되는 쿼리 중 하나는 모든 독후감을 조회하는 것입니다. 여기서 likeCount는 Likes 테이블에 접근하여 공유된 독후감에 대한 '좋아요' 수를 계산하는 데 사용됩니다. 이 likeCount 부분에 캐시를 적용하여 성능을 개선해 보겠습니다.

 

첫 번째 조회

첫 번째 데이터 조회 682ms

💡 데이터를 처음 조회할 때의 성능을 측정했습니다. 첫 번째 조회가 일반적으로 가장 느리므로, 정확한 성능 비교를 위해 캐시를 비우고(flushall) 진행된 두 번째 조회 시간과 세 번째 조회 시간으로 비교하겠습니다.

 

두 번째 조회

두 번째 데이터 조회 204ms
두 번째 조회 전/후 flushall

💡 2번째 조회 전/후에는캐시를 비워줍니다.

💡 데이터 베이스에는 총 7개의 공유 게시글이 있습니다.

조회 성능

세 번째 조회

세 번째 데이터 조회 111ms
조회 성능



✅ 첫 번째 조회 기준으로는 682ms -> 111ms로 조회 성능이 개선된 것을 확인할 수 있었습니다.

(682ms - 111ms) % 111ms 로 계산하였을 때 대략 514.41% 의 성능이 개선되었습니다.

 

✅ 두 번째 조회 기준으로는 204ms -> 111ms 로 조회성능이 개선된 것을 확인할 수 있었습니다.

(204ms - 111ms) % 111ms 로 계산하였을 때 대략 83.78% 의 성능이 개선되었습니다.

 

감사합니다!😋