GridView + ObjectDatasource 문제 - 크고 작은 결과 세트에 대한 똑같이 나쁜 성능
-
03-07-2019 - |
문제
최근에 오래된 .NET 레거시 웹 앱에서 작업하라는 부름을 받았습니다. 시스템의 데이터 양이 4 배가 되었기 때문에 성능은 최근에 상당히 하위 부위로 떨어졌습니다. 지난 2 년 동안 괜찮 았습니다.
.xsd 파일을 사용하여 저장된 절차와 대화하여 결과를 충분히 좁히고 (페이징은 없지만) ObjectDatasource를 통해 그리드 뷰에 공급했습니다.
내가 머리를 잡을 수없는 부분, 140 또는 1200의 1 결과를 위해로드하는 데 약 7 초가 걸렸습니까? (Gridview는 Pagination을 처리하고 있습니다)
SQL 프로파일 러를 사용하여 쿼리가 6.9 초가 걸린다는 것을 알 수있었습니다. SQL Management Studio에서 동일한 매개 변수로 동일한 쿼리를 실행하면 100ms가 걸렸습니다. 캐시 된 결과가 아닌지 확인하기 위해 매개 변수를 변경했습니다. 긴 대기 시간은 확실하게 재현 가능합니다.
나는 그것을 알고있다 페이징 구현 여기서 완료해야하지만 지금은 페이지가 수행되는 이유 뒤에 설명을 찾으려고 노력하고 있습니다. 마찬가지로 작고 큰 세트의 경우 ...
(GridView의 'Simple'디스플레이는 필요에 맞습니다. HTML을 제어 할 필요가 없습니다)
해결책
우리는 매우 같은 문제를 가지고 있습니다.
- 통계가 최신 상태인지 확인하십시오.
SELECT ObjectName = Object_Name(ind.object_id), IndexName = ind.name, StatisticsDate = STATS_DATE(ind.object_id, ind.index_id) FROM SYS.INDEXES ind order by STATS_DATE(ind.object_id, ind.index_id) desc
- SQL Server 캐시를 떨어 뜨립니다.
DBCC DROPCLEANBUFFERS DBCC FREEPROCCACHE
- 도움이되지 않으면 "Inner Loop Join"및 "with (index = ...)"와 같은 힌트로 SSMS 쿼리 계획을 시행 할 수 있습니다.
다른 팁
응용 프로그램에서 전송 된 실행 계획과 매개 변수 유형을 살펴볼 수 있습니다. 예를 들어, 응용 프로그램이 nvarchar를 전달하여 Varchar 열과 비교하여 문제를 일으킬 수 있습니다.http://weblogs.sqlteam.com/tarad/archive/2007/11/16/60408.aspx