리스트의 각 ROW 마다 쿼리가 요청 되는게 정상일까요?

[루비궁금]

안녕하세요

외주 개발업체에서 제작한 루비 소스를 인계 받아서 살펴 봤습니다.

저는 루비를 잘 모릅니다.

디비나 로그상에서 보면 특이하다고 해야 할지 이상한 부분이 있어서 의견을 구하고자 글을 올립니다

-----------------------------------------------------------------------------------------------------------------------------------------------------

기본적으로 데이타 요청/입력/수정 등이 모두 모델 객체 파일을 기본으로 하여 작동 하는것같습니다.

이를 ORM 이라고 부르는것 같습니다.

-----------------------------------------------------------------------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------------------------------------------------------------------

그런데 개발된 소스에서 거의 대부분 리스트의 쿼리가 요청 되는 부분을 살펴보면

리스트 건당 쿼리가 요청 되고 있는 것 같습니다.

-----------------------------------------------------------------------------------------------------------------------------------------------------

아마도 단일 테이블이면 한번의 요청으로 끝나지 않았을가 예상하는데

대부분 테이블을 조인하여 요청 되는 부분이라 belongs_to, has_many ? 등으로 엮인 테이블의 정보들이 리스트의 각 row 마다 요청 되고 있는것 같습니다

이걸 정상적인 걸로 봐야 할까요?

루비에 대한 경험이 없어서 그런데, 루비언어에서는 이렇게 작동 하는게 정상이라고 봐야 할까요?

다른 언어를 수년 해오면서, 이런식의 쿼리 요청이 굉장히 비정상적으로 보입니다.

실제 루비온레일스 실행시 로그를 보면 어떠한 리스트 페이지의 경우는 거의 100개 가까운 쿼리가 요청되는 경우도 보입니다

(일부 CACHE 로 처리되어 앞서 요청된 결과를 재활용 하는 것 같아 보이나, 이를 제외한다 해도 너무 과한 쿼리가 요청 되고 있습니다)

그래서 DB에서도 요청된 쿼리를 저장해서 살펴봐도 리스트 row 당 쿼리가 요청되어 이상해서 의견을 듣고 싶습니다

이렇게 되는게 정상일까요?

[아샬]

N + 1 queries problem은 다음 문서를 참고하시면 좋을 것 같습니다.

http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations

--

---
이 메일은 Google 그룹스 '한국 루비 사용자 모임' 그룹에 가입한 분들에게 전송되는 메시지입니다.
이 그룹에서 탈퇴하고 더 이상 이메일을 받지 않으려면 rubykr+unsubscribe@googlegroups.com에 이메일을 보내세요.
https://groups.google.com/group/rubykr에서 이 그룹을 방문하세요.
더 많은 옵션을 보려면 https://groups.google.com/d/optout을(를) 방문하세요.

[김명성]

아샬님 감사합니다,

답글이 많은 도움 되었습니다.

외주업체에서 관련 처리를 하나도 안한것 같네요,

검수해보니 어떤 페이지는 리스트 요청시 현재 370개의 쿼리가 요청 되고 있었습니다.

역시 이건 굉장히 비정상적으로 작업을 한거네요

이런 업체를 어떻게 해야 할까요,

저렇게 작업하고 돈만 달라고 하니, 괘씸하네요,,

감사합니다

2018년 5월 15일 화요일 오후 9시 54분 32초 UTC+9, 아샬 님의 말:

이 그룹에서 탈퇴하고 더 이상 이메일을 받지 않으려면 rubykr+un...@googlegroups.com에 이메일을 보내세요.

[Seong Hoon Lee]

안녕하세요 루비로 개발한 외주 개발 업체라 하시니 혹시 저희 회사가 진행한 프로젝트일 수도 있고 아니라 해도 저희도 앞으로 비슷한 문제제기를 받을 수 있을 것 같다는 생각이 들어 답변 남겨봅니다. 우선은 저희가 작성 중인 코드를 보고 미리 반성하게 됩니다. 저희가 담당해서 아직 개발이 진행되고 있고 최적화가 이루어지기 전의 프로젝트들을 살펴보면 데이터가 많이 표시되는 페이지의 경우 쿼리가 꽤 많이 날아갑니다. 

저희가 개발하는 과정을 예로 들면, 고객사의 요청 사항을 빠르게 반영하고자 처음에는 쿼리 최적화에 신경을 덜 쓰는 편입니다. 레일스의 액티브 레코드를 이용해 belongs_to, has_many 등의 메서드 체인으로 쿼리 수를 고려하지 않고 컨트롤러와 뷰를 구현하면 개발 결과물은 굉장히 빨리 나오고 기획 상의 변경 때문에 발생하는 기능 수정사항에 대해서도 다른 프레임워크보다 훨씬 빠르게 대응이 가능한 반면, 쿼리 로그를 찍어보면 쿼리 캐싱을 감안하더라도 쿼리량이 꽤 많아요. 

서버 자원(호스팅 비)보다 개발자의 시간 자원(개발비)이 비싸다는 전제하에 변경이 빈번한 부분의 최적화를 하는데 사전에 시간 자원을 사용하는 것이 비효율적이라고 생각하고 있어서 입니다. 중간 결과물까지도 성능 보다는 구현 생산성에 집중하면서 구현을 해나가다가 요청 사항 구현이 거의 마무리 되어 테이블 구조나 UI 구현이 거의 확정되고 출시가 얼마 남지 않은 시점에 includes, joins 등으로 쿼리수를 줄이고 카운터 캐시 칼럼을 만들고 주요 컬럼 조합에 맞추어 DB 인덱스를 추가하고 페이지 캐시 등의 처리를 진행합니다. 특히 접속량이 많을 것으로 예상되는 페이지부터 순차적으로 쿼리 최적화, 인덱스, 캐싱을 진행하면 출시 시점에 퍼포먼스 이슈가 발생하는 경우는 많이 줄어듭니다. 

최적화 과정을 거치기 전에 제 3자가 코드를 뜯어보았을 때 합당한 문제제기를 할 수 있을 것 같아서 저희도 내부적으로 반성하고 개발 과정에서도 기본적인 쿼리 튜닝을 해야겠다는 생각을 하게 되었습니다. 저희가 진행했던 프로젝트이든 그렇지 않든 저에게 연락을 주시면 살펴보고 대응해드리거나(저희 고객사라면) 도움드릴 수 있는 부분(다른 개발사가 진행했다면)이 있는지 같이 이야기해보면 좋을 것 같습니다. 

제 연락처는 010.9391.6522 입니다. 밤이든 주말이든 언제든 연락주세요

감사합니다

인썸니아 이성훈 드림 

2018년 5월 15일 화요일 오후 9시 39분 24초 UTC+9, 붕붕 님의 말:

[Sangmin Ryu (aka. Simon)]

최적화 시간을 주지 않고 개발을 외주했겠죠. ;;

2018년 5월 17일 (목) 오전 2:45, 김명성 <giod...@gmail.com>님이 작성: