<aside> 💡

nGrinder 를 활용한 부하테스트, 캐싱을 활용한 성능개선

목적

• 부하테스트를 통해 트래픽을 발생시키고, 분석 후 성능 개선
• 약 60000건의 공지사항 데이터를 조회하는 API 성능 개선
• 공지사항 데이터를 페이징 조회 시 API 성능 개선
• 캐싱을 활용한 성능 개선

용어

• TPS(Transactions Per Second) : 평균 TPS
• Peak TPS : 최고 TPS
• Mean Test Time: 평균 테스트시간
• Executed Tests: 테스트 실행 횟수
• Successful Tests: 테스트 성공 횟수
• Errors: 에러 횟수
• Run time: 테스트 실행 시간(Duration) </aside>

기능별 부하테스트

• 총 두가지의 케이스에 대해 부하테스트 진행
  • 60000건의 공지사항 전체 데이터를 조회 시 캐싱 전/후 부하테스트 결과
  • 공지사항 페이징 조회 시 캐싱 전/후 부하테스트 결과

<aside> 💡

1. 60000건 의 공지사항 전체 데이터를 조회하는 작업

• GET /api/notice

공통 부하테스트 조건

• 가상 사용자(Vuser) : 10명
• Duration : 1분
• 프로세스 : 2
• 스레드 : 5

전체 조회 성능 수치 변화 결과 캐싱전 → 후

결론

• 대용량 데이터 조회 캐싱 시 성능이 탁월하게 좋아짐

캐싱 시 TTL(Time To Live) 20초 설정, 60초 설정 시 성능 수치 결과

• 다른 설정은 동일하게 진행

• 예상으로는 TTL 20초 설정보다 60초 설정 시 캐싱 데이터가 장기간 유지되어 API 요청 리소스가 줄어들고, 성능이 개선된 결과를 예상하였지만, TPS, 실행 건수가 전반적으로 소폭 성능이 감소됨

TTL 을 길게 설정 시 성능이 감소한 원인

1. 메모리 사용량 증가

   • TTL 이 길어질수록, 캐시데이터의 유효기간이 늘어나고, 메모리 사용량이 증가함
   • LRU, LFU 교체 알고리즘의 경우, 오래된 데이터를 계속 유지하려는 알고리즘 → 성능 저하 발생 가능성
   • 스카우터로 모니터링한 결과, TTL 설정이 길어질 수록, CPU 의 사용률이 높아져 알림이 많이 발생됨

   

   TTL 20초 - 스카우터 모니터링 로그

   

   TTL 60초 - 스카우터 모니터링 로그

2. 동시성(Concurrency) 이슈

   • TPS 성능은 요청 처리 속도, 동시처리 가능한 수준에 영향을 받음
   • TTL 이 길어질수록, 캐시에 오래된 데이터가 길게 유지됨 → 동일한 캐시 키에 요청이 몰리는 경우, 동시성 문제가 발생할 수 있음
   • 동시성 이슈에 대한 해결 방안에는 분산 락, Lazy Expiration 등이 있음

3. GC(Garbage Collection) 부하

   • TTL 이 길어질수록, 캐시 데이터의 수명이 늘어나고, 힙 메모리에 오래 유지됨 → GC 가 오래된 데이터를 정리하며 처리시간이 증가될 수 있음
   • 해결 방안으로, 메모리 관리가 있음(적절한 크기, 교체정책(LRU, LFU) 설정

캐시 적용 전 부하테스트

• 가상 사용자 : 10명
• Duration : 1분

캐시 적용 전 부하테스트 수행결과

• TPS : 11.1
• Peak TPS : 15.0
• Mean Test Time : 897.31 ms
• Executed Tests : 583 건
• Error : 0
• Run time : 1 분

캐시 적용 후 부하테스트

• 가상사용자 10명, Duration 1분
• 캐시 TTL(Time To Live) 설정 : 20초

캐시 적용 후 부하테스트 수행결과

• TPS : 59.2
• Peak TPS : 86.0
• Mean Test Time : 167.86 ms
• Executed Tests : 3003 건
• Error : 0
• Run time : 1 분 </aside>

<aside> 💡

2. 공지사항 데이터를 페이징 조회하는 작업

• GET /api/notice/page?size=100&page=[pageNum]

• nGrinder 스크립트 설정

공통 부하테스트 조건

• 가상 사용자(Vuser) : 10명
• Duration : 1분
• 프로세스 : 2
• 스레드 : 5
• @Cachebale - condition 옵션
• pageNum 5 이하만 캐싱(6~10 페이지는 캐싱 적용하지 않음)

@Transactional(readOnly = true)
@Cacheable(value = "noticeCache",
           key = "'noticeCache-'+ #pageable.pageNumber",
           condition = "#pageable.pageNumber <= 5")
public Page<Notice> findPageNotice(Pageable pageable) {
    Page<Notice> notices = noticeRepository.findAll(pageable);
    // put 메소드를 사용하여 key 설정
    cacheManager.getCache("noticeCache").put("noticeList" + pageable.getPageNumber(), notices);
    return notices;
}

페이징 조회 성능 수치 변화 결과 캐싱전 → 후

| --- | --- | --- | --- |

결론

• 대용량 데이터 조회 시 캐싱 기능보다는 개선율이 작지만, 성능이 유의미하게 개선됨

캐시 적용 전 부하테스트

• 가상 사용자 : 10명
• Duration : 1분

캐시 적용 전 부하테스트 수행결과

</aside>