Entity Framework/Glimpse Duration Disparity

Question

최신 ASP.NET MVC 및 Entity Framework (MVC 5.2.2, EF 6.1.2) 및 최신 Glimpse를 사용하고 있습니다. 여러 개의 중첩 된 자식 개체가있는 엔티티를 열심히로드하는 쿼리 시간을 개선하고 탐색 속성을 가져 오기 위해 .Include ("Object.Child")를 사용하여 쿼리 수를 줄였습니다. 처음에 나는 좋은 결과를 얻고 있다고 생각했는데, Glimpse의 SQL 탭에서 "Total query execution time"이 현저하게 줄어들었다. 그러나 "총 연결 열기 시간"은 높게 유지되며 그 결과 결합 된 메가 쿼리에 대해 매우 길다. 아래 스크린 샷을 참조하십시오.

두 사람의 차이점이 무엇인지 알 수있는 사람이 있는지 궁금합니다. Glimpse는 내 명령이 < 100ms 걸리지 만 SQL 연결이 5 초 이상 걸린다 고 말합니다. 이 경우 쿼리는 많은 조인 등으로 인해 지저분하지만 실제로 쿼리 자체가 100ms 이내에 완료되는 경우 시간이 어디로가는 지 명확하지 않습니다.

참고 : 여기서 why two durations에 대한 답변을 보았지만 각각의 특성을 설명하지는 않습니다. 질문을위한

Answer 1

감사합니다. 연결 기간의 타이머는 연결이 열릴 때 시작되고 닫히면 완료됩니다. 이 작업을 더 진행하려면 컨텍스트/연결을 어떻게 사용하고 있습니까? 공유하고 있습니까?

Answer 2

추가 테스트를 마친 후에 무슨 일이 일어나고 있는지 알았습니다. 엔티티 프레임 워크에서 계층 적 엔티티를 열심히로드하는 .Include() 접근 방식은 많은 조인과 결과 집합의 데이터 복제가 포함 된 복잡한 쿼리가 될 수 있다고 제안한 또 다른 질문을 보았습니다. 내 속성 중 하나로서 XML 문자열이 길었습니다. 따라서 데이터베이스에서 여러 번 복제하면 반환/처리하는 데 시간이 오래 걸립니다.

테스트로 데이터 무거움 필드를 지우고 쿼리를 다시 작성하여 훨씬 짧은 "연결"기간 (오른쪽에서 엿볼)을 얻었습니다. 총 9 초에서 200ms 미만으로 진행되었습니다. 이를 바탕으로 데이터 크기가 범인이라고 가정하고 큰 데이터 속성을이 방법으로 사용하는 것에 대한 내 교훈을 얻었습니다.

Glimpse가 쿼리에서 반환되는 원시 데이터를 보여줄지 또는 레코드 수와 함께 크기를 바이트 단위로 표시할지 여부는 계속 알고 싶습니다. 이것은 아마도이 문제를 분명히했을 것입니다.

Answer 3

이 질문에 조금 늦었지만 동일한 문제가 발생했으며 쿼리 실행 시간과 연결 열기 시간 사이의 불일치를 이해하려고했습니다.

FWIW, 필자는 뷰 모델의 열거 형을 구체적인 목록이 아닌보기로 전달하고 있음을 발견했습니다. 따라서 뷰는 쿼리의 평가를 트리거하고 연결이 열린 채로 남아있는 시간을 연장합니다. 항목의 목록 (열거 형에 .ToList() 호출)을 전달하면 I 이 매우 많아은 연결이 열린 채로 남아있는 시간을 줄였습니다.