SMALL
오늘의 공부
오늘은 프로젝트의 아이디어 게시글 전체 조회 에 대해서 성능 테스트를 하였다.
EC2 에 아래와 같은 설정을 통해 실제로 테스트 해보았다.
OS | Ubuntu 22.04 |
AWS 인스턴스 | t2.micro |
CPU | vCPU(가상 CPU) 1 core |
Memory | 3G( Memory 1G + Swap 2G ) |
데이터 건수 | 유저 10만건, 아이디어 게시글 100만건 |
3000건
서버 CPU, RAM 그래프
2000건
서버 CPU, RAM 그래프
300건
서버 CPU, RAM 그래프
이러한 문제로 성능 개선이 필요할것 같다. 아래의 에러가 뜬다.
먼저 생각 해보고 검색 결과
현재 코드에서는 아래와 같이 if 문을 통해 전체 검색인지 단건 조회인지 검색인지 판단하고 그에 해당하는 리스트를 반환해준다. 또한 불필요한 데이터를 끌고 오는 동시에 응답받는 속도가 낮아 진다. 해당 Database < - > Application 속도를 높일려고 먼저 QueryDSL 를 통해 필요한 데이터만 DTO 로 변환해서 돌려주는 식의 작업이 필요할것 같고,
또한 검색에 필요한 Title 컬럼에 Indexing 을 걸어 검색에 최적화 할수 있게 할수 있을것 같다.
또한 데이터 캐싱에 대한 방법이 있다. Redis 같은 캐싱을 적용시켜 1차캐시 같은 느낌으로 쓸수 있다.
하지만, 이에 방법은 비용이 발생함으로써 제일 우선순위 마지막에 두어야 할것 같다. 또한 데이터베이스 연결 최적화를 할 수 있을것 같다. HikariCP 는 Java 환겨에서 데이터베이스 연결 풀 라이브러리 이라고 한다.
성능과 안전성에서 좋은 평가를 받고 있다하니 시도할만한것 같다.
HikariCP 는 좀더 정리해서 Spring 카테고리에 추가해서 봐야될것같다.
@Transactional(readOnly = true)
public List<IdeaResponse> findAllIdea(String keyword, Category category, Integer page) {
if (StringUtils.hasText(keyword) && !Objects.isNull(category)) {
throw new IdeaFindException(IdeaFindErrorCode.KEYWORD_CATEGORY_SAME);
}
List<IdeaResponse> findList;
Sort sort = Sort.by(Sort.Direction.ASC, "createdAt");
Pageable pageable = PageRequest.of(page, 10, sort);
if (StringUtils.hasText(keyword)) {
findList = ideaRepository.findAllByTitleContaining(keyword, pageable).stream()
.map(IdeaResponse::from)
.collect(Collectors.toList());
} else if (!Objects.isNull(category)) {
findList = ideaRepository.findAllByCategory(category, pageable).stream()
.map(IdeaResponse::from)
.collect(Collectors.toList());
} else {
findList = ideaRepository.findAll(pageable).stream()
.map(IdeaResponse::from)
.collect(Collectors.toList());
}
return findList;
}
내일은?
내일은 팀원분들과 함께 조회 기능에 대해 성능 개선을 어떻게 할건지에 대한 토의가 필요할것 같다.
반응형
LIST
'TIL' 카테고리의 다른 글
2023.08.19 (0) | 2023.08.19 |
---|---|
2023-08-17 - JMeter / 성능 개선 (0) | 2023.08.17 |
2023.08.15 (0) | 2023.08.16 |
2023.08.14 (0) | 2023.08.14 |
2023.08.13 (0) | 2023.08.13 |