2012-05-31 2 views
1

나는 리피터를 렌더링하는데 270 초가 걸리고 실제로 모든 브라우저를 망가 뜨리는 리피터가있다. 데이터를 검색하는 SQL은 약 10 초가 걸립니다. Eval을 제거하여 속도가 향상되는지 확인하고 싶지만 올바른 구문에 문제가 있습니다. 150,000 개의 레코드를 처리 할 때 성능이 실제로 향상 될지 의심 스럽습니다. GridView 또는 다른 컨트롤이 더 빨라지겠습니까? LINQ to SQL을 사용하면 성능이 향상됩니까?리피터에서 Eval을 사용하지 않고 성능을 향상시키는 올바른 방법은 무엇입니까?

<%#Eval("Name")%> 

내가 노력하고 있어요 : 여기에 평가에 대한 코드입니다

<%# ((DataRowView)Container.DataItem)["Name"]%> 

는 그러나 위에서 작동하지 않습니다. 그것은 DataRowView가 표현식으로 사용될 수 없다고 말합니다.

또한 페이징과 관련이 없음을 지적 할 것입니다.

+0

데이터 소스는 어떤 유형입니까? – jrummell

+0

@jrummell - SQL을 데이터 테이블로 가져온 다음 리피터에 바인드하는 메소드가 있습니다. 나는 SqlDataSource, ObjectDatasource 등을 사용하지 않는다. – Xaisoft

+0

여기의 문제는 평가가 아니라 테이블 (그리고 div가 아님)에 대한 렌더링이지, 게으른로드는 아니지만 모두 메모리에로드되고 뷰 스테이트는 당신은 gridview와 함께 할 수 있습니다. – Aristos

답변

1

Eval 또는 Container.DataItem 중 하나를 사용하면 동일한 것이므로 차이가 없습니다. 이 SO을 살펴보십시오.

데이터를 표시 할 때 브라우저가 충돌하는 경우 너무 많은 결과 HTML 또는 자바 스크립트가 브라우저에서 렌더링되기 때문입니다. Eval은 서버 측에서 실행되므로 브라우저 충돌의 근본 원인이 아닙니다.

성능을 향상시키고 충돌을 피하기 위해 페이징을 사용하는 것이 좋습니다. 정말 페이징을 사용할 수 없다면 CSV 파일을 Excel 또는 PDF 파일로 열어 다운로드하는 방법은 어떻습니까?

성능을 향상시키기 위해 Linq를 사용하는 경우, 나는 당신이 저장 프로 시저 또는 동적 SQL과 비교하고 있다고 가정합니까? 저장 프로 시저가 항상 최상의 성능을 제공하지만 일단 동적 SQL 또는 linq 식 (또는 컴파일 된 linq)이 SQL Server에 캐시되면 sproc과 비교할 때 속도가 느립니다.

+0

제공 한 링크는 Eval ("var") %> 또는 <% # DataBinder.Eval (Container.DataItem, "var") %>을 비교합니다. Eval을 사용하는 다른 방법은 <% # ((Object) Container.DataItem) .var %>를 사용하는 것입니다. 성능 테스트를 해보니 개인적으로 차이는 없습니다. –

관련 문제