Redis Cache 성능 측정

 

 

1. API 설명 

음식점 예약 어플을 제작 중에 있다.

특정 조건에 따른 음식점 리스트를 출력하고자 한다.

성능 개선을 위해 캐시를 활용할 것이며 뚜렷한 변화가 있는지 측정하고자 한다.

 

입력 : 나라명, 도시명, 동명, 음식점 타입, 페이지, 페이지 당 크기

출력 : 해당 조건에 맞는 음식점 리스트

 

 

2. 기존 코드

- 서비스 클래스의 메서드

@Override
  public HashMap<String, Integer> getStoreList(String country, String city, String dong, String type, int page, int size) {
    return storeDAO.getStoreList(country, city, dong, type, page, size);
  }

 

- DAO 클래스의 메서드

@Override
  public HashMap<String, Integer> getStoreList(String country, String city, String dong, String type, int page, int size) {
    List<StoreEntity> storeInfo = queryFactory.select(storeEntity).from(storeEntity)
        .where(storeEntity.country.eq(country).and(storeEntity.city.eq(city))
            .and(storeEntity.dong.eq(dong)).and(storeEntity.type.eq(type)))
        .limit(size).offset(page * size).fetch();
    HashMap<String, Integer> result = new HashMap<>();
    for(StoreEntity info : storeInfo) {
      result.put(info.getStoreName(), info.getStoreId());
    }
    return result;
  }

 

- 해당 API는 조건에 맞는 데이터를 찾아 출력하고자 하는 형식에 맞추어 데이터를 생성하고 이를 반환해준다.

 

 

 

3. 기존 코드 성능 측정

- 1000건의 요청을 기준으로 하였다.

- 평균적으로 1.392초 안에 요청을 받을 수 있었다 즉, 고객이 요청시 1.392초 정도면 데이터를 받을 수 있었음을 의미한다.

- 하지만 평균은 그렇지만 어떠한 고객은 0.034초 안에 데이터를 받았지만 어떠한 고객은 3.039초가 걸려서 데이터를 받을 수 있었다.

 

 

 

 

4. 캐시를 사용한 코드

- 서비스 클래스의 코드

@Override
  public HashMap<String, Integer> getStoreList(String country, String city, String dong, String type, int page, int size) {
    String address = country + city + dong + type + page + size;
    Optional<StoreListDTO> storeList = storeListCache.findById(address);
    if (storeList.isEmpty() == true) {
      HashMap<String, Integer> new_storeList = storeDAO.getStoreList(country, city, dong, type, page, size);
      StoreListDTO storeListDTO = new StoreListDTO(address, new_storeList);
      storeListCache.save(storeListDTO);
      return new_storeList;
    }
    return storeList.get().getStoreList();
  }

- 처음 요청에 대해서 캐시를 확인 후 해당 키 값을 갖는 데이터가 캐시에 없다면 데이터를 DB에서 가져온다. 이 후, 데이터를 캐시에 저장하고 데이터를 반환한다.

- 이 후, 다른 요청에 대해서 만약 데이터가 캐시에 있다면 데이터를 캐시에서 꺼내서 반환해준다.

 

 

 

5. 개선 코드의 성능 측정

- 1000건의 요청에 대해서 평균적으로 0.023초 안에 데이터를 받을 수 있었다.

- 가장 적게 걸린 유저는 0.003초, 가장 오래 걸린 유저는 0.183초이지만 모두 훨씬 적기에 유저가 쾌적하게 데이터를 받을 수 있음을 유추할 수 있다.

 

 

 

 

6. 요청 수 증가

기존 코드에 2000 스레드 요청

 

캐시 사용 코드에 2000 스레드 요청

- 요청을 두배로 늘렸을 때, 서버 대수가 한대이기 때문에 대역폭의 문제로 속도 차이가 많이 나는 것을 우선적으로 확인할 수 있다.

- 요청에 대해서 여전히 응답 속도에 차이가 난다. 평균 4초의 속도를 0.061초로 줄일 수 있었고 최대 응답 시간은 7.5초에서 0.278초로 줄일 수 있었다.

 

 

 

 

7. 결론

- 캐시를 사용시 눈에 띄는 속도차이가 발생함을 확인할 수 있다.

- 유저의 관점으로 봤을 때, 유저는 7.5초안에 받을 수 있었던 데이터를 0.278초안에 데이터를 받을 수 있게 되었다.

- 서버의 관점으로 봤을 때, 평균적으로 데이터 처리 시간을 4.073초에서 0.061초로 처리시간을 줄일 수 있었다.

- 요청이 많은 정보에 대해서는 캐시 사용은 필수적이라고 생각이 든다.

 

- 추가적으로 캐시는 저장 시간을 설정할 수 있다. 실제 작업환경에서 접속사 수나 여러가지를 고려해서 캐시 저장시간에 대해서도 측정해보면 좋을 것 같다.