Spring 성능 개선 - 캐시 사용하기 (Enhcache)
1. Ehcache 추가
1.1 의존성 추가
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-cache</artifactId>
</dependency>
<dependency>
<groupId>net.sf.ehcache</groupId>
<artifactId>ehcache</artifactId>
</dependency>
1.2 ehcache.xml 추가
<?xml version="1.0" encoding="UTF-8"?>
<ehcache>
<defaultCache
maxElementsInMemory="1000"
maxElementsOnDisk="0"
eternal="false"
statistics="false"
timeToIdleSeconds="10"
timeToLiveSeconds="10"
overflowToDisk="false"
diskPersistent="false"
memoryStoreEvictionPolicy="LRU"/>
<cache
name="NoticeReadMapper.findAll"
maxElementsInMemory="10000"
maxElementsOnDisk="0"
eternal="false"
statistics="false"
timeToIdleSeconds="10"
timeToLiveSeconds="10"
overflowToDisk="false"
diskPersistent="false"
memoryStoreEvictionPolicy="LRU"/>
<cache
name="NoticeReadMapper.findByPage"
maxElementsInMemory="10000"
maxElementsOnDisk="0"
eternal="false"
statistics="false"
timeToIdleSeconds="10"
timeToLiveSeconds="10"
overflowToDisk="false"
diskPersistent="false"
memoryStoreEvictionPolicy="LRU"/>
</ehcache>- name : 캐시명
- maxElementsInMemory : 메모리에 저장할 수 있는 최대 요소 수
- maxElementsOnDisk : 디스크에 저장할 수 있는 최대 요소 수
- eternal : 캐시 항목이 영원히 유지되는지 여부 -> false로 설정되어 있긴하다만 캐시 항목은 유효기간(timeToLiveSeconds) 혹은 유휴기간(timeToIdleSeconds)이 지나면 제거된다.
- statistics : JMX 통계정보 갱신 옵션
- timeToIdleSeconds: 설정된 시간 동안 유휴상태시 갱신 -> 캐시된 데이터가 사용 되지 않은 채로 유지되는 최대 시간
- timeToLiveSeconds: 설정된 시간 동안 유지 후 갱신 -> 캐시 된 데이터의 전체 수명
- overflowToDisk : 메모리에 캐시된 데이터가 메모리 한계를 초과하는 경우 디스크로 넘길지 여부 지정
- diskPersistent: 디스크에 저장된 데이터가 시스템 재시작 후에도 유지되어야 하는지 여부
- memoryStoreEvictionPolicy: 메모리가 꽉 찼을 때 데이터 제거 알고리즘 옵션
1.3 ehcache Configuration 추가
EhCache를 사용할 수 있도록 EhCacheManagerFactoryBean과 EhCacheCacheManager를 Bean으로 등록
import org.springframework.cache.CacheManager;
import org.springframework.cache.annotation.EnableCaching;
import org.springframework.cache.ehcache.EhCacheCacheManager;
import org.springframework.cache.ehcache.EhCacheManagerFactoryBean;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Primary;
import org.springframework.core.io.ClassPathResource;
@Configuration
@EnableCaching
public class EhcacheConfiguration {
@Bean
@Primary
public CacheManager cacheManager(EhCacheManagerFactoryBean ehCacheManagerFactoryBean) {
return new EhCacheCacheManager(ehCacheManagerFactoryBean.getObject());
}
@Bean
public EhCacheManagerFactoryBean ehCacheManagerFactoryBean() {
EhCacheManagerFactoryBean ehCacheManagerFactoryBean = new EhCacheManagerFactoryBean();
ehCacheManagerFactoryBean.setConfigLocation(new ClassPathResource("ehcache.xml"));
ehCacheManagerFactoryBean.setShared(true);
return ehCacheManagerFactoryBean;
}
}2. 캐시 사용하기
@Cacheable 사용하기 : value속성은 캐시의 이름, ehcache.xml 구성 파일에서 <cache>엘리먼트의 name과 일치시키도록 하자
@Override
@Cacheable(value = "NoticeReadMapper.findAll")
@Transactional
public List<Notice> getAllNotices() {
return noticeReadMapper.findAll();
}
@Cacheable 옵션 활용
@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);
}
NoticeReadMapper.findByPage" 로 캐시 이름은 동일한데 1page에 대한 캐시인지 2page에 대한 캐시인지 어떻게 구분할까
- 캐시의 키를 동적으로 생성하기 위한 SpEL식을 지정한다.
- 메소드의 파라미터를 이용하여 특정 파라미터 값을 기반으로 캐시 키를 생성할 수 있다.
- condition속성은 캐시가 적용되기 위한 추가적인 조건을 지정할 때 사용한다. -> true인 경우에만 캐시적
- 여기선 pageNumber가 5이하인 경우에만 캐싱처리
2. nGrinder로 캐시 전후 성능테스트 1 - 요청당 5000건 조회
- 요청 당 5000건에 공지사항 전체 데이터를 조회
- uri : get /api/notices
- 캐시 적용 전
- Vuser:10
- Duration: 1분
- 캐시 적용 후
- Vuser:10
- TTL 20초
- Duration 1분
<defaultCache
maxElementsInMemory="1000"
maxElementsOnDisk="0"
eternal="false"
statistics="false"
timeToIdleSeconds="20"
timeToLiveSeconds="20"
overflowToDisk="false"
diskPersistent="false"
memoryStoreEvictionPolicy="LRU"/>
<cache //이하생략- TTL을 20초로 설정했기 때문에 20초로 수정했다. (원래 10초였다)
2.1 캐싱 적용 전
먼저 캐시 어노테이션에 주석 처리
@Override
//@Cacheable(value = "NoticeReadMapper.findAll")
public List<Notice> getAllNotices() {
return noticeReadMapper.findAll();
}
다음으로 스크립트를 셋팅할 것이다.
아래와 같이 스크립트와 테스트를 셋팅한다.
1분 테스트 결과 아래와 같은 정보를 얻을 수 있다.
환경에 따라 테스트 결과가 달라질 수 있지만, 꽤 무거운 API이므로, 그리 높은 TPS수치를 보여주진않는다.
이제 캐시를 적용한 후 동일한 테스트를 진행해보자
2.2 캐시 적용 후
캐시 적용 후 TPS
한 눈에 봐도 TPS 수치가 많이 좋아진 것을 확인할 수 있다.
3. nGrinder로 캐시 전후 성능테스트 1 - 1~10 page 랜덤 조회
--> page에 대한 요청을 랜덤으로 보내기 위해 스크립트에 api 요청을 살짝 수정했다.
@Test
public void test() {
def page = new Random().nextInt(10)+1
def apiUrl = "http://127.0.0.1:8081/api/notices/${page}"
HTTPResponse response = request.GET(apiUrl, params)
if (response.statusCode == 301 || response.statusCode == 302) {
grinder.logger.warn("Warning. The response may not be correct. The response code was {}.", response.statusCode)
} else {
assertThat(response.statusCode, is(200))
}
}
- 성능 테스트 환경
- uri : get /api/notices/{page}
- 캐시 적용 전
- Vuser:10
- Duration: 1분
- 캐시 적용 후
- Vuser:10
- TTL 20초
- Duration 1분
3.1 캐시 적용 전 성능
- 요청당 10건의 데이터만 가져오므로, 꽤 준수한 TPS 수치를 보여준다.
3.2 캐시적용 후
- 캐싱은 최신 데이터를 위주로 보는 특성을 고려하여 5page까지만 적용했다.
평균 TPS : 980 -> 1326 대략 35% 증가
Peek TPS : 1302 - > 1930 대략 48% 증가
Mean Test Time : 9 -> 6 대략 33%감소
Exected Tests: 53,296 -> 74,966 대략 40% 증가
4. 모니터링 툴을 통한 수치 변화 - 공지사항 전체
- 캐시 사용 전
X로그 (맨 오른쪽), TPS를 보면 3초 이내에 응답을 하고있음을 볼 수 있다.
Heap Used -> 증가했다, 줄어들었다를 반복 -> 이는 자바의 GC가 조회한 데이터를 응답하고 사용하지않는 객체를 free하기 때문 (GC count 탭을 추가하면 확인 가능)
*실무에서 모니터링 툴 확인 팁
CPU -> 60% ~40% 이하 유지 [CPU 사용량이 꾸준하게 80~90%라면 위험할 수 있다]
XLog를 통해 10초 혹은 그 이상 걸리는 트랜잭션이 있으면, 이유를 찾는다 -> 스카우터를 통해 어느정도 확인 가능
- 캐시 사용 후
캐시 적용 후 에는 0.2초 이내에 빠르게 응답함을 볼 수 있다.
GC는 이전에 비해 더 많이 발생하게 된다.
또한 1분동안 더 많은 응답을 처리하므로 CPU 사용량이 더 크다.