캐싱으로 조회 성능 개선하기 2

작성일 | In

캐싱으로 조회 성능 개선하기 1 : https://rustywhite404.github.io/etc/2024/09/27/Data_Cache/
이번에는 key와 condition을 이용하여 원하는 캐시만 가져올 수 있도록 해 보았다.

1. 코드 작성 및 실행

  1. ‘/api/notices/{page}`를 입력하면 해당 페이지의 데이터만 가져오도록 코드를 작성한다.
1
2
3
4
5
6
7
//controller 
@GetMapping("/{page}")
    public ResponseEntity<Object> findByPage(HttpServletRequest request, @PathVariable("page") Integer page) {
        List<Notice> notices = noticeService.findByPage(request, page);
        return new ResponseEntity<>(notices, HttpStatus.OK);
    }


1
2
3
4
5
6
7
//service 
@Override
    @Cacheable(value = "NoticeReadMapper.findByPage", key = "#request.requestURI + '-' + #pageNumber", condition = "#pageNumber <= 5")
    public List<Notice> findByPage(HttpServletRequest request, int pageNumber) {
        int startIdx = (pageNumber - 1) * 10;
        return noticeReadMapper.findByPage(startIdx);
    }
  1. 서비스를 실행시켜본다.
    이미지
    2페이지와 5페이지를 한 번씩 호출 해 봤다.
    이미지 그런 다음 캐시 데이터를 확인해보면 key = /api/notices/2-2, /api/notices/5-5로 키가 생성 되어 있는 게 보인다.
    위에 작성한 service 레이어에서 condition을 #pageNumber <= 5으로 설정해두었기 때문에 pageNumber가 6 이상이면 호출해도 캐시메모리가 생기지 않는다.

2. key와 condition의 활용

이번에 캐시의 키를 requestUrl과 pageNumber을 활용하여 생성해 본 것처럼, 다양한 형태로 키를 만들어 사용 할 수 있을 것 같다. 제일 많이 활용 할 것 같은 부분은 역시 page 구분이다.
condition은 캐시가 적용되기 위한 추가적인 조건을 지정 할 수 있도록 해 준다. 처음에는 어떨 때 사용하면 좋을 지 잘 와닿지 않았는데, 강의에서 예시로 들어주신 공지사항 게시판에 활용한 사례를 보니 이해가 빨랐다. 공지사항의 경우 최신 데이터들 위주로 보게 되고, nn페이지의 내용은 잘 확인하지 않는데 모든 데이터를 다 가져오는 건 확실히 비효율적이다. 이런 경우 key와 condition을 사용하여 최근 n페이지의 데이터만 캐시로 처리해두면 편리할 것 같다.