기록

Batch Size

(오차범위가 살짝 있음 +/- 0.4s 정도)

기존 API 처리 시간: (최초)4.493s > 1.8s ~ 2.5s
batch_size 100 적용: (최초)1.158s ~ 1.586s > 0.1s
batch_size 300 적용: (최초)1.123s ~ 1.501s > 0.1s
batch_size 500 적용: (최초)1.011s ~ ,,, > 0.1s

batch size는 100으로 해도 무관할 듯(사이즈가 커진다고 성능이 좋아지는 것은 아님) (JVM warmup에 대해서도 알아보기)

Fetch Join

Cafe, CafeMenuCategory 는 1:N 관계
name으로 cafe 조회 후 cafe_id를 가지고 category 조회할 것이기에 query 한 개 더 호출 불필요하게 query 하나 더 호출되는 것보다 fetch join으로 하나로 묶는 것이 좋아 보임
(여기서 QueryDSL 활용)

override fun findDetailFetchJoinByName(name: String): Cafe? {
    return jpaQueryFactory
        .selectFrom(cafe)
        .join(cafe.cafeMenuCategories, cafeMenuCategory).fetchJoin()
        .where(cafe.name.eq(name))
        .fetchOne()
}

참고로 Entity안에 nested 관계 상관없이 2개 이상의 OneToMany에 대해 fetch join을 하는 경우 에러 발생
(MultipleBagFetchException)

Cache(Redis)

기록 참고
DB I/O를 줄이는 용도로 Cache 적용

beaniejoy / dongne-cafe-api

Cafe 상세 조회 API 성능 개선(QueryDSL, batch_size, Cache) #86

기록

Batch Size

Fetch Join

Cache(Redis)

References