유경상 (ksyu@tysystems.com)
비효율적인 작업
앞서 데이터그리드의 컨트롤 계층 구조가 언제 생성되는가에 대해 논의했다. 데이터 바인딩이 수행될 때와 LoadViewState에서 컨트롤 계층 구조가 만들어진다고 했을 것이다. 데이터그리드의 페이징 시나리오를 살펴보자. 최초로 페이지가 열릴 때 우리는 대개 다음과 같이 데이터그리드에 바인딩을 수행하고 PageIndexChanged 이벤트 핸들러를 구현할 것이다.
앞 코드의 문제점은 이렇다. 페이징을 위해 LinkButton이 클릭되면 포스트 백이 발생하고 포스트 백의 LoadViewState 과정 중에 컨트롤 계층 구조가 생성된다. 이 결과 수백 개의 웹 컨트롤이 생성된다. 그리고 PageIndexChanged 이벤트가 수행됨에 따라 데이터 바인딩이 수행되고 그 결과 다시 수백 개의 웹 컨트롤이 생성될 것이다. LoadViewState의 단계에서 만들었던 컨트롤은 모두 쓸데없는 것들이 되어 버린 것이다. 이와 같이 데이터그리드는 다소 비효율적인 작업을 수행하곤 한다.
ViewState의 의존도
데이터그리드는 많은 정보를 ViewState에 기록한다. 데이터그리드의 주요 속성들(AllowPaging, AllowSorting 등)은 물론이요 각종 스타일 정보 등을 ViewState에 기록한다. 솔직히 이들 속성은 웹 페이지 내에서 상수인 경우가 대부분이므로 굳이 ViewState에 기록할 필요는 없다.
데이터그리드의 ViewState 의존도 중에서 가장 좋지 못한 것은 ViewState가 없으면 포스트 백이 발생했을 때 자식 컨트롤의 계층 구조를 전혀 만들지 않는다는 점이다. 자식 컨트롤들이 만들어 지지 않으면 이벤트가 자식 컨트롤로 전달되지 않으며 자식 컨트롤이 이벤트를 받지 못하면 이벤트 버블링도 발생하지 않음은 너무도 자명하다. 그 결과 페이징, 정렬 등의 이벤트 역시 발생하지 않게 되어 버린다. 쉽게 페이징, 정렬을 사용할 수 있기 때문에 사용하는 데이터그리드이지만 이를 위해 희생해야 할 요소가 점차로 무겁게만 느껴지는 것은 바로 이 때문일 것이다.
데이터그리드 성능 테스트
지금까지 데이터그리드의 문제점을 진단해 보았다. 말로만 하지 말고 실제로 테스트를 통해 앞서 언급한 문제들이 어떻게 작용하는가 살펴보자. 테스트는 두 개의 600MHz CPU와 512MB의 메모리를 갖춘 서버급 컴퓨터에서 닷넷 프레임워크 1.1을 사용했고 테스트에 사용된 도구는 비주얼 스튜디오 닷넷 엔터프라이즈 아키텍처 버전에 포함된 Application Center Test(ACT)를 사용했다. 데이터베이스에 대한 조회가 병목되지 않도록 데이터는 미리 읽어 캐시해 두었으며 페이지에서 캐시된 데이터를 바인딩했다. 웹 페이지는 8개의 데이터 레코드를 표시하며 페이징과 정렬 기능을 사용했으며 다른 효과를 최소화하기 위해 매우 간단히 작성했다(<화면 2>).

<화면 2> 테스트에 사용된 웹 페이지
첫 번째 테스트는 ViewState를 enable시켜 놓고 테스트했으며 두 번째 테스트는 ViewState를 disable시켜 놓았다. 테스트 결과는 <표 2>와 같다. 서버가 초당 처리하는 페이지 갯수는 ViewState를 disable했을 때 약 70% 정도 더 많이 처리했으며 응답 속도는 80% 정도 더 빨랐다. 이로써 데이터그리드 컨트롤의 ViewState가 enable되어 있을 때의 문제점이 명확해졌다. 비록 데이터베이스를 액세스하는 부분이 병목되어 이러한 ViewState의 오버헤드가 잘 나타나지 않기도 하지만 말이다. 그렇다고 무조건 ViewState를 disable할 수도 없다. ViewState가 disable되면 페이징, 정렬 등의 기능을 사용할 수 없기 때문이다.

데이터그리드의 확장
이번 연재에서는 웹 컨트롤의 대표 주자(?) 격인 데이터그리드 컨트롤의 구조와 작동 방식 등을 살펴봤다. 그리고 데이터그리드의 어떤 부분이 문제인가를 살펴보고 관련된 테스트도 수행해 보았다. 이제 남은 것은 지금까지 살펴본 내용을 바탕으로 문제점을 해결하는 것이다.
정리 | 박은정 whoami@korea.cnet.com
비효율적인 작업
앞서 데이터그리드의 컨트롤 계층 구조가 언제 생성되는가에 대해 논의했다. 데이터 바인딩이 수행될 때와 LoadViewState에서 컨트롤 계층 구조가 만들어진다고 했을 것이다. 데이터그리드의 페이징 시나리오를 살펴보자. 최초로 페이지가 열릴 때 우리는 대개 다음과 같이 데이터그리드에 바인딩을 수행하고 PageIndexChanged 이벤트 핸들러를 구현할 것이다.
private void Page_Load()
{
if (!Page.IsPostBack) {
DataGrid1.DataSource = GetData();
DataGrid1.DataBind();
}
}
h
private void DataGrid1_PageIndexChanged(object sender,
DataGridPageChangedEventArgs e)
{
DataGrid1.CurrentPageIndex = e.NewPageIndex;
DataGrid1.DataSource = GetData();
DataGrid1.DataBind();
}
{
if (!Page.IsPostBack) {
DataGrid1.DataSource = GetData();
DataGrid1.DataBind();
}
}
h
private void DataGrid1_PageIndexChanged(object sender,
DataGridPageChangedEventArgs e)
{
DataGrid1.CurrentPageIndex = e.NewPageIndex;
DataGrid1.DataSource = GetData();
DataGrid1.DataBind();
}
앞 코드의 문제점은 이렇다. 페이징을 위해 LinkButton이 클릭되면 포스트 백이 발생하고 포스트 백의 LoadViewState 과정 중에 컨트롤 계층 구조가 생성된다. 이 결과 수백 개의 웹 컨트롤이 생성된다. 그리고 PageIndexChanged 이벤트가 수행됨에 따라 데이터 바인딩이 수행되고 그 결과 다시 수백 개의 웹 컨트롤이 생성될 것이다. LoadViewState의 단계에서 만들었던 컨트롤은 모두 쓸데없는 것들이 되어 버린 것이다. 이와 같이 데이터그리드는 다소 비효율적인 작업을 수행하곤 한다.
ViewState의 의존도
데이터그리드는 많은 정보를 ViewState에 기록한다. 데이터그리드의 주요 속성들(AllowPaging, AllowSorting 등)은 물론이요 각종 스타일 정보 등을 ViewState에 기록한다. 솔직히 이들 속성은 웹 페이지 내에서 상수인 경우가 대부분이므로 굳이 ViewState에 기록할 필요는 없다.
데이터그리드의 ViewState 의존도 중에서 가장 좋지 못한 것은 ViewState가 없으면 포스트 백이 발생했을 때 자식 컨트롤의 계층 구조를 전혀 만들지 않는다는 점이다. 자식 컨트롤들이 만들어 지지 않으면 이벤트가 자식 컨트롤로 전달되지 않으며 자식 컨트롤이 이벤트를 받지 못하면 이벤트 버블링도 발생하지 않음은 너무도 자명하다. 그 결과 페이징, 정렬 등의 이벤트 역시 발생하지 않게 되어 버린다. 쉽게 페이징, 정렬을 사용할 수 있기 때문에 사용하는 데이터그리드이지만 이를 위해 희생해야 할 요소가 점차로 무겁게만 느껴지는 것은 바로 이 때문일 것이다.
데이터그리드 성능 테스트
지금까지 데이터그리드의 문제점을 진단해 보았다. 말로만 하지 말고 실제로 테스트를 통해 앞서 언급한 문제들이 어떻게 작용하는가 살펴보자. 테스트는 두 개의 600MHz CPU와 512MB의 메모리를 갖춘 서버급 컴퓨터에서 닷넷 프레임워크 1.1을 사용했고 테스트에 사용된 도구는 비주얼 스튜디오 닷넷 엔터프라이즈 아키텍처 버전에 포함된 Application Center Test(ACT)를 사용했다. 데이터베이스에 대한 조회가 병목되지 않도록 데이터는 미리 읽어 캐시해 두었으며 페이지에서 캐시된 데이터를 바인딩했다. 웹 페이지는 8개의 데이터 레코드를 표시하며 페이징과 정렬 기능을 사용했으며 다른 효과를 최소화하기 위해 매우 간단히 작성했다(<화면 2>).

첫 번째 테스트는 ViewState를 enable시켜 놓고 테스트했으며 두 번째 테스트는 ViewState를 disable시켜 놓았다. 테스트 결과는 <표 2>와 같다. 서버가 초당 처리하는 페이지 갯수는 ViewState를 disable했을 때 약 70% 정도 더 많이 처리했으며 응답 속도는 80% 정도 더 빨랐다. 이로써 데이터그리드 컨트롤의 ViewState가 enable되어 있을 때의 문제점이 명확해졌다. 비록 데이터베이스를 액세스하는 부분이 병목되어 이러한 ViewState의 오버헤드가 잘 나타나지 않기도 하지만 말이다. 그렇다고 무조건 ViewState를 disable할 수도 없다. ViewState가 disable되면 페이징, 정렬 등의 기능을 사용할 수 없기 때문이다.

데이터그리드의 확장
이번 연재에서는 웹 컨트롤의 대표 주자(?) 격인 데이터그리드 컨트롤의 구조와 작동 방식 등을 살펴봤다. 그리고 데이터그리드의 어떤 부분이 문제인가를 살펴보고 관련된 테스트도 수행해 보았다. 이제 남은 것은 지금까지 살펴본 내용을 바탕으로 문제점을 해결하는 것이다.
다음 연재에서는 ViewState를 disable한 상태에서도 페이징과 정렬 등의 기능을 사용할 수 있도록 데이터그리드 컨트롤을 확장해 볼 것이다. 이 컨트롤은 DataGridEx라 부를 것이며, 기존 웹 컨트롤을 바탕으로 이를 확장하는 일반적인 방법을 먼저 살펴본 후에 DataGridEx를 구현해 볼 것이다. 이번 연재에서 살펴봤던 문제점을 제거하기 위한 방법을 살펴보고 이 방법에 대한 장단점 역시 살펴볼 것이다. 미리 예습을 해보고 싶은 독자가 있다면 참고자료에 나타낸 MSDN 라이브러리의 항목이나 관련 서적을 살펴보길 바란다. 다음 연재를 기대하는 독자가 있기를 바라며...
정리 | 박은정 whoami@korea.cnet.com
"ASP.NET" 카테고리의 다른 글
- In Depth ASP.NET using ADO.NET (0)2007/04/29
- ASP.NET Execution Model (4)2006/07/30
- 풍성한 ASP.NET 개발환경의 이해 1 - 4 (0)2006/03/17
- 풍성한 ASP.NET 개발환경의 이해 1 - 3 (0)2006/03/17
- 풍성한 ASP.NET 개발환경의 이해 1 - 2 (0)2006/03/17

수안이의 컴퓨터 연구실



Leave your greetings.