List 와 Page 그리고 Slice
현재 나의 홈화면은 모든 상품을 나타내는 화면이다. 즉, 홈화면을 나타내는 것만으로도 모든 데이터를 접근하는 쿼리문이 실행이 된다는 것인데 그렇다면 그 상품을 가져오는 방법은 무엇이 있을까? JPA를 이용한 페이징 방법에는 List, Page, Slice 이렇게 사용할 수 있다.
Page와 Slice
이전에 작성한 Page와 Slice를 비교하는 블로그이다.
https://latewalk.tistory.com/152
페이징(Pagination)
프로젝트를 제작하다 보면 정말 많은 양의 데이터를 다루게 되는 경우가 있다. 또한 그 방대한 양의 데이터를 사용자에게 전달할 일이 필요 할 때가 있다. 그때 사용자가 요청한 모든 값을 가져
latewalk.tistory.com
List
추가적으로 모든 데이터를 가져오는 것에 List또한 생각해 볼 수 있는데 사실 이것은 모든 데이터를 가져와서 하나씩 모든 값을 보내주는 것인데 설명만 봐도 대용량 데이터를 다루는 테스트에서 이점이 존재하지 않을 것이라고 생각한다.
쿼리값 또한 어떠한 offset, limit가 없기 때문에 그저 select 문에 불과하다
혹시 모를 분들을 위해서 말씀드리자면 여기서 말씀드리는 findAll()의 기능에서 사용하는 select문은 해당 테이블에 있는 모든 데이터를 가져와서 나타내는 쿼리문입니다.
하지만 테스트를 하는 시점에서 장점이 있을 것이다. 라고 생각을 하고 테스트를 진행해보려 한다.
테스트 시작
이번 테스트 또한 JMeter 를 이용한 성능 테스트를 진행하려는 목적이다.
각각의 성능 실험은 이렇게 진행된다.
1. List, Page, Slice 의 성능 테스트를 위해 각각 로직 작성
나는 상품을 미리 등록해두었다. 5만개의 데이터를 저장해두었고 이를 검색하는 것이다.
Page 와 Slice 설정은 상당히 뒤쪽에 있는 데이터를 불러오는 것이 성능을 체크하는 것에 더욱 확연한 효과가 있을 것이라고 생각했다. 물론 List는 모든 데이터를 가져오기에 페이지와 사이즈를 굳이 설정해줄 필요가 없다.
로직의 준비는 마쳤다.
2. Jmeter 의 준비
내가 비교하려고 하는 것은 과부하를 걸어서 실험하는 것이 아닌 응답속도를 비교하고자한다. 때문에
Number of Thread ( 사용자 수 ) : 100명
Ramp-up : 1초에 한번 요청
Loop Count : 총 1번 요청
이처럼 3가지의 성능을 비교해보는 상황을 가져보자
테스트 결과
결과 예상
- List : 사실 성능을 상승시키고자 사용하기엔 너무 별로다. 모든 결과를 가져오는 것은 홈화면을 새로고침하는 경우 계속해서 큰 데이터를 가져온다. 이것은 굉장히 안좋을 것이라는게 예상된다.
- Page : List 보다는 빠른 효과를 가져오게 될 것이다. 왜냐하면 쿼리문에 시작지점과 몇개의 데이터를 가져올 것인지 명시되어 있기 때문에 인덱스를 통해 검색을 하고 거기서 부터만 데이터를 빼와서 구성을 하면 되기 때문이다. 물론 count 때문에 fullscan을 하는 과정에 시간이 좀 걸리지만 List 보다는 훨씬 빠르다.
- Slice : 이것이 가장 빠를 것이다. Page처럼 시작점과 몇 개의 데이터를 가져올지 사이즈까지 해결하고 심지어 Slice는 count쿼리문을 실행하지 않고 현재 가져온 데이터 뒤에 +1 을 통한 데이터의 유무만을 검사하여 결과를 보내주기 때문에 쿼리문을 최대한 요약했다 라고 볼 수 있다.
결과
1. List
처참한 결과가 나왔다. 결과가 처음 눈에 보이는 것은 32초부터 시작된다. 당연히 쓰고 싶은 생각은 없었지만 더욱 사라지게 만드는 결과이다. 밑에 TPS 를 보면 로컬임에도 불구하고 1.6이라는 처참한 결과를 보여준다.
2. Page
확실히 모든 데이터를 가져오는 List보다는 확연히 빠른 속도를 보여주고 있다. 쿼리문 자체가 제한을 주고 id를 통한 인덱스값으로 데이터를 찾고 그 범위의 내용만 가져다 주려고 하니 확실히 빠르다. TPS 또한 근 0.4초를 향하고 있다.
3. Slice
Slice는 Page에 비해 count 쿼리문을 생략함으로써 약간 더 빠른 응답 속도를 보여준다. 이것은 로컬에서 실행한 결과로 만약 더욱 큰 서비스에서 비교하게 되면 이 차이는 점점 더 커지게 될 것이다.
결과값 비교하기
List | Page | Slice | |
쿼리문 | WHERE가 없는 SELECT문 | 1. WHERE가 없는 SELECT문 2. count 쿼리 존재 |
WHERE가 없는 SELECT문이지만 limit에 +1을 시켜 뒤에 데이터가 더 존재하는지 확인 |
평균 응답 시간 | 33.3초 | 0.39초 | 0.32초 |
TPS | 1.6 TPS | 62.2 TPS | 66.8 TPS |
결론
성능을 봐서는 Slice를 사용하는 것이 좋다. 그렇다면 무조건 Slice를 쓰는 것이 옳은것일까? 그건 아니다. 우리는 다양한 서비스를 만들게 될테고 우리가 표현하고자 하는 내용은 각자 다를 것이다. 그때마다 적절하게 선택하면 된다.
무조건 Slice를 선택하는 것이 능사는 아니라는 것이다. 페이지를 사용하고자 하는 부분에서는 어느정도의 성능 저하를 감수하더라도 사용자의 편의를 위해 페이지를 사용하는 것이 좋을것 같다.
나의 경우에는 리뷰는 페이지를 사용해서 나타냈다. 상품에 비해 많은 데이터를 가지고 있지 않을 확률도 높고 나는 리뷰가 스크롤을 통해 보는것이 아닌 한 눈에 다 보이는것을 원했기 때문이다.
이런식으로 내가 표현하고자하는 방식 때론 사용자가 보기 편한 방식으로 나타내는 것에 따라 사용하면 될 것 같다.
하지만 list는 진짜 고민을 많이 해봐야한다...꼭 사용해야 할까...? 너무 느려지는데
'프로젝트 > 개인 프로젝트' 카테고리의 다른 글
Postman을 통한 테스트 자동화(Feat. 테스트 시나리오) (1) | 2023.10.13 |
---|---|
EC2의 서버와 로컬 서버의 응답 시간은 왜 차이가 나는 것일까? (0) | 2023.09.12 |
Global Exception & Business Exception(예외 처리) (0) | 2023.09.08 |
페이징(Pagination) (0) | 2023.09.08 |