보통은 엔티티를 조회할 때 모든 컬럼을 다 가져오지 말고 필요한 칼럼만 조회하라는 이야기를 많이 한다.
우선, Eager와 Lazy부터
Eager로 fetch하는 방식은 성능측면에서 권장되지 않는다.
연관관계에 있는 것들을, 모두 처음부터 fetch를 하는 데 처음부터 이 연관관계의 엔티티가 필요하지 않기 때문이다.
그 엔티티가 필요할 때 연관관계를 로딩하는 lazy 전략이 실무에서 많이 쓰인다.
여기에 더해 고려해볼 게 있다.
엔티티를 변경할 목적이 아니라면? 모든 데이터가 다 필요한 게 아니라면? 굳이 엔티티 전체를 로딩할 필요가 없다. 메모리에 올라오는 컬럼수가 적어지는 만큼, 메모리 사용도 절약할 수 있을 것이다.
처음 매칭 가능한 파트너를 조회할 땐 이렇게 10mb 정도의 메모리 사용량이 올라간다.
그 이후로는 jvm 내부에서 캐싱을 하기 때문인지 2mb정도로 시간이 줄어든다.
매칭 가능한 파트너를 조회할 때 한번에16MB나 사용하고 있다 ....
그 뒤로는 jvm내부에서 캐싱을 하는 것인지 2mb로 줄어든다.
이제 최적화를 해보자
여기서 user는 profile을 조회하기 위해서 사용되는 것이다.
참고로 필드명은 컬럼이름과 정확히 일치해야 한다.
이렇게 Profile을 DTO로 가져오게 했다.
메모리 사용량의 변화는 딱히 보이지 않는다.
여러번 하면 동일하게 2mb정도로줄어든다.
레디스를 사용해보자
레디스에 키를 처음 넣는것과 db조회까지 같이할 땐 30mb정도가 들어간다.
레디스에 캐시가 있는 상태에선 쿼리가 8개에서 5개로 줄어들고, JVM과 JPA 최적화덕분에 2mb안팍으로 메모리를 사용한다.
레디스에 키가 있으면 DB 조회를 줄일 수 있다는 이점이 매우 크기에 계속 이렇게 사용할 것이다.
