(06.29) 수정됨.
로그인 시에만 글 목록 뷰의 작동 시간을 잡아먹던 범인을 찾았다.
바로 subQuery와 outerRef다.
댓글 수, 추천수, 조회수 등의 정보를 서브쿼리와 아우터알이에프를 통해 어노테이트했다.
그런데, 서브쿼리를 사용하는 경우 join을 사용하는 것이 아니라 select를 사용한다는 사실을 이번에 알게 되었다.
join을 사용한다면 성능에 그리 큰 영향을 주지 않을 텐데, outerRef로 전달된 pk의 수가 20개, 30개 이런 식으로 증가하다보니 이 모든 pk와 비교하는라고 속도가 느려지는 것이었다.
덕분에 굳이굳이굳이 subQuery로 구현해두었던 코드를 모두 수정해야했다....
다행인 점은 이번에 코드를 수정하며 덩어리진 함수를 여러 파편으로 잘게 나누었는데, 그 덕인지 모델을 대폭 수정하고 뷰 코드는 조금만 수정하는 것으로 그쳤다는 점이 다행이랄까.
많은 개체를 가져올 때 subQuery를 사용하면 속도에 영향을 주지만, 1개 또는 소수의 개체를 가져올 때는 크게 영향을 주지 않는 듯 하다.
개별 글 페이지만 확인했을 때는 속도에 영향이 없던 건 이런 이유였나 보다.
개중에는 서로를 참조하지 않고, pk값만 int 필드로 기록하던 모델도 있었는데, 이런 경우에는 나중에 실제 값을 추가하는 식으로 구현해야 했다.
만약 이런 데이터를 기준으로 정렬을 해야 한다면 굉장히 곤혹스러운데, 다행히 이런 경우 pk 값을 특정 순서로 가져온 다음, 그 순서에 맞춰서 쿼리셋 순서를 정렬시킬 수 있는 방법이 있었다.
장고) pk 리스트에 등록된 순서대로 오브젝트를 가져오기 예제