API 성능 테스트, 12초→0.57초로 향상(with batch fetching)

API 성능 테스트 (with fetch join)

(1) 예상

• 1번 방식) 기존 api에서 center 정보 가져올 때
• 기존 쓰던 대로 api 쓰면 됨(서버 통신 그대로)
• 센터 정보 찾는 쿼리 날릴 때 최적화 쉬움
• jpa에서 제공하는 fetch join+batch 기능을 사용해서 쿼리 수가 n/배치사이즈으로 줄어들고 중복데이터는 안가져와서 최적화 쉬움
• select * from center where id in (1,2,3)
• 같은 트랜잭션 내에서 조회해오기에 데이터 일관성을 보장할 수 있음

• 2번 방식) 새로운 api에서 center 정보 추가로 가져올 때
• api를 한 번 더 날려야 함(서버 통신 + 1)
• 센터 정보 찾는 쿼리 날릴 때 최적화 어려움
• id 100개면 쿼리도 100번 날려야 함 → n
• select * from center where id=1
• select * from center where id=2
• 설령 in 절 사용하더라도 배치 처리 따로 또 해주지 않으면 최적화 힘듦
• select * from center where id in (1,2,1) → 중복은 in이 알아서 처리해준다.
• 배치 처리만 안된다.

(2) 결과

• 아래 코드를 컨트롤러 단에 넣어주어 측정했다. 아 근데 포스트맨 사용 중이면 포스트맨에도 실행 시간 뜬다.

• 2번 방식 테스트 전 짧막한 수정)
• 어….. ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 70개 가져오는데 12초
• 문제의 레거시 쿼리…..
• findById 사용하게 바꿔줬다. fetchAll은 필요가 없으니,, 아마 센터 상세 조회 api가 저 쿼리 사용하는 함수를 같이 쓰고 있어서 문제일 텐데 일단 테스트용이니 잠깐 바꿔줘자.
• 3.8초로 줄었지만 그래도 여전히 오래 걸린다.
• 조금 더 최적화해서 in절 사용하게 해보자..

• 1번 방식) fetch join
• 0.734초

• 2번 방식) 일반 select
• 70개 가져오는 데 0.3초 + 4.1초
• in절 사용할 땐 70개 가져오는 데 0.3초 + 0.27초 = 0.57초

참고

[스프링부트] 코드 실행 시간 측정

서론 프로젝트를 진행하면서 이중 for문을 사용하는 코드를 짜는 스스로가 너무 싫어서 코드 실행 시간을 확인해볼 필요성을 느꼈다. 본론 두 가지 방법이 있다는 걸 확인했다. 첫 번째는 자바를 배울 때 사용해서 기존에 알고 있던 방법이었다. long startTime = System.currentTimeMillis(); // 실행 코드 long stopTime = System.currentTimeMillis(); System.out.println("코드 실행 시간: " + (stopTime - startTime)); 두번째는 스프링에서 제공하는 stopwatch 방법이다. StopWatch stopWatch = new StopWatch(); stopWatch.start(); // 실행 코드 stopWatc..

https://danpung2.tistory.com/54

[Java] API 시작/종료 로그 사용하여 API 실행 시간의 통계 구하기

API 성능 테스트 중 이슈가 생겼다jmeter로 전자가격표시기에 이미지를 출력하는 API의 시간을 측정하고자 하는데, 그 중 "이미지 생성" 시간을 로그를 통해 추출해야 했다.이미지 생성 시간 역시 jmeter로 API 실행 시간의 통계를 구할 수도 있으나, 이미지

https://velog.io/@zinna_1109/API-시작종료-로그-사용하여-API-실행-시간의-통계-구하기

(3) 후속 테스트

• 1번 방식과 2번 방식의 차이가 애매한데, 좀 더 많은 양의 데이터로 좀 더 정교하게 비교해보기로 했다.

• 일단 가져오는 데이터 필드를 똑같게 만들어줬고 데이터 양을 둘다 똑같이 902개로 늘렸다.
순서 보장
• MySQL 무순서성 : 순서 보장 안되므로 정렬 넣어줬다
• 추가로.. hashMap을 쓰고 있어서 더욱 순서 보장이 안되었다. LinkedHashMap으로 바꿔줬다. 사실 이것만 해줘도 순서 보장 된다.

• 1번 방식) fetch join (select in)
• 0.688초 ~ 0.9xxx초
기존 쿼리

• 2번 방식) select in
• 0.554초 + 0.322초 = 0.8xxx초
기존 쿼리
select in 쿼리

• 여전히 비슷하다. 더이상 데이터 늘리려면 query string 자리가 부족해지기에 여기까지만 테스트하고 정리했다.

(4) 결론

• 1번 방식을 사용하기로 했다. 직적 쿼리 짤 필요 없이 같은 성능으로 간단히 최적화해주기 때문이다.

N+1문제와 batch

• 정의) 연관 관계가 설정된 엔티티를 조회할 경우에 조회된 데이터 갯수(n) 만큼 연관관계의 조회 쿼리가 추가로 발생하여 데이터를 읽어오는 현상

• 특징) batch를 사용해 fetch join을 하면 in 절로 select 해와 N+1 문제를 해결할 수 있다.

• 참고)
Beware of hibernate batch fetching
Last week, I was exploring how to avoid N+1 selects problem when loading associations or collections for an entity in hibernate. I went down a lot of interesting paths and came up with so many fasc…

https://prasanthmathialagan.wordpress.com/2017/04/20/beware-of-hibernate-batch-fetching/

JPA : N+1 문제 및 해결방법 정리
N+1문제 N+1은 1번의 쿼리만 의도를 했었는데, 실제 쿼리가 실행되는 시점에서는 쿼리가 N개가 더 나가는 문제다. 이 문제가 일어나게 되면 당연한 이야기지만, 의도하지 않은 쿼리가 나가게 되면서 급격히 성능이 안 좋아지는 것을 느낄 수 있다고 한다. 공부하는 입장에서는 와닿지 않지만, DBA분에게 바로 이상하다고 연락이 온다고 한다. N+1 문제 발생 상황 N+1 문제는 주로 다대일 연관관계의 엔티티를 여러 개를 불러왔을 때 생기는 것 같다. 이를테면 위와 같은 상태에서 자주 발생하는 것으로 보인다. 코드로 하나하나 살펴보려고 한다. 먼저 셋팅 코드를 공유한다. Team teamA = new Team(); teamA.setName("teamA"); em.persist(teamA); Team teamB..

https://ojt90902.tistory.com/640