Querydsl+Fetch Join을 통해 N+1문제 개선했는데, 성능이 나아지지 않습니다.

Question

N+1문제를 개선해서 4 + N 개의 쿼리가 호출되는 걸 1개의 쿼리로 줄였습니다.게시글 id를 통해 단일 게시글을 조회하는 API 입니다.우선, 단일 게시글을 조회하면 다음과 같은 응답 데이터가 내려집니다.게시글의 내용(Post), 게시글 작성자(User), 게시글이 속한 주거정보(HouseInfo), 달린 댓글들(List)이렇게 4개의 쿼리가 호출된 다음, List 형태의 댓글들을 작성한 댓글 작성자에 대한 정보가 추가로 N번 조회됩니다.연관 관계는 다음과 같습니다.Post:User (N:1 양방향)Post:HouseInfo(N:1 단방향)Post:PostComment(1:N 양방향)PostComment:User(N:1 단방향)다음과 같이 fetch join을 통해 한번에 조회하도록 하였습니다.@Override public Optional findPostById(long postId) { Post post1 = jpaQueryFactory.selectFrom(post) .leftJoin(post.user, user).fetchJoin() .leftJoin(post.houseInfo, houseInfo).fetchJoin() .leftJoin(post.postComments, postComment).fetchJoin() .leftJoin(postComment.user, user).fetchJoin() .where(post.id.eq(postId)) .fetchOne(); return Optional.ofNullable(post1); }무조건 N+1 문제를 개선하면 성능이 좋아질거라 생각했지만, 그러질 않아서 도대체 어느 부분이 성능을 저하시키는 건지 잘 모르겠습니다ㅜ (여기서 성능은 nGrinder를 통해 측정한 API 응답 시간입니다)제 생각에는 필요없는 필드까지 fetch join에 의해 모두 가져오기 때문에 성능이 저하되는 건 아닌가 싶습니다. (단일 게시글 조회를 하였을 때, 응답되는 각 엔티티의 필드는 3개정도씩입니다)그래도 1000개의 N이 발생하는 상황을 비교해봤을 때, 4+999개와 1개의 쿼리문 차이는 무조건 성능이 개선될 수 밖에 없다고 생각됩니다.성능이 개선되지 않는 이유에 대해서 전혀 감이 잡히지 않는데, 혹시라도 '어떤 요인 때문에 성능 저하가 발생할 수 있겠다'라는 원인을 말해주신다면 정말 감사드리겠습니다 ㅠ (개선해야할 포인트도 함께 알려주신다면 더더욱 감사하겠습니다!)

집킨 · Accepted Answer

성능 최적화는 단순히 nGrinder로 측정 했을때 나오는 수치만으로는 예측하기 힘듭니다인덱스가 잘 걸려있고 DB서버의 스펙이 충분히 좋고 네트워크 상태가 좋고 현재 측정중인 쿼리가 슬로우 쿼리가 아니고, 이 쿼리 외에 부하가 없는 상태에서는 별 차이가 없을수도 있고 있을수도 있는거죠우선 가장 먼저 해야할건, 정말 성능이 안좋은건지 부터 측정해야합니다목표 tps를 정하고 측정을 해보세요그리고 실제 실행되는 쿼리를 보고, 디비 구조를 한번 봐야합니다물론 디비외에 앱서버에서도 병목 원인이 있는지도 봐야하구요

kotliner · Answer

그래서 부하테스트에서 중요한 부분은 모니터링입니다. 간단하게는 어느 부분에서 지연시간이 늘어나는지 로깅해서 확인하는것부터 해서 복잡하게는 jvm 로그를 보는경우도 있습니다. 일단 어느 구간에서 지연이 발생하고 어느 구간에서 병목이 생기는지 확인하는게 첫번째로 해야할 일입니다. 그러기 위해서는 어플리케이션에서 생기는지 장비에서 생기는지 cpu나 메모리가 다 차서 느려지는건지, 아니면 단순 네트워크 대역폭을 다쓴건지, db와의 커넥션풀이 다찼는지, db가 실제로 느려지는지, jvm 힙이 다 차는지, 내부 커넥션풀이 다 차는지 여러 부분을 종합적으로 살펴봐야합니다.

mirheeoj · Answer

프로파일링이 그래서 중요한 것입니다. 병목현상이 어디서 발생하는지 정확히 알아야 하거든요. 예컨대 가정 내 수압 문제를 해결하려고 집 수도관 전체를 뜯어서 직선화했는데 정작 집으로 들어오는 수압 자체가 낮은 것이었으면 리소스를 낭비해버린 셈이 됩니다. 말씀하신 부분은 그런 프로파일링을 통해 쿼리의 비효율성이 주범임을 확신하고 나서 해야 할 일이라고 할 수 있습니다.

Querydsl+Fetch Join을 통해 N+1문제 개선했는데, 성능이 나아지지 않습니다.

3개의 답변

#fetchjoin 목록