때때로 우리의 웹 애플리케이션은 로컬에서 테스트할 때 매우 빠르지만 LAN에서 테스트할 때 성능 문제가 발견될 수 있습니다. 때로는 LAN에서 정상적인 속도의 애플리케이션도 WAN에서 발견될 수 있습니다. 이러한 문제는 일반적으로 애플리케이션의 부주의나 오류로 인해 발생하며 시스템 아키텍처와는 관련이 없으며 실제 환경에서 디버깅 및 테스트를 통해 문제를 찾아 해결할 수 있습니다.
오늘 우리가 이야기할 내용은 아키텍처 개선을 통해 ASP.Net 응용 프로그램의 성능을 근본적으로 향상시키는 것입니다.
먼저 ASP.Net의 몇 가지 간단한 응용 프로그램을 테스트해 보겠습니다.
테스트 환경: AthlonXP 3200+, DDR400 512M, WindowsXP SP2, 기본 SQL Server 2000, 중국 Northwind 데이터베이스 제품 테이블(Access에서 가져옴), 약 70개 레코드.
| 테스트 일련번호 | 프로그램 종류 | 테스트 방법 | 테스트 결과 (초당 요청) | SQLServer 리소스 점유 | ASP.Net 점유된 리소스 |
| 1 | 웹 서비스는 | DataSet을 제품 테이블로 채우고 레코드 수를 | 250번 | 100% | 반환합니다.- |
| 2 | 웹 서비스는 | DataSet을 제품 테이블로 채우고 DataSet을 | 138번 | 반환합니다.54% | 46% |
| 3 | 웹 애플리케이션이 | 채웁니다. DataSet을 제품 테이블과 함께 반환하고 Bind DataGrid를 | 70번 | 반환합니다.28% | 72% |
첫 번째 테스트에서 웹 서비스는 데이터베이스에서 레코드를 읽고 이를 DataSet에 채우고 레코드 수를 반환합니다(레코드를 반환하지 않음). 시스템 리소스를 거의 차지하지 않는다고 가정합니다. SQL Server가 리소스를 완전히 점유하고 있으므로 부정적인 영향이 있을 것이라는 결론이 명확하지 않습니다.
두 번째 테스트에서는 웹 서비스가 DataSet을 반환하면 초당 요청 수가 거의 절반으로 줄어들고 ASP.Net에서는 DataSet을 직렬화하는 데 사용됩니다.
웹 응용 프로그램이 DataSet을 DataGrid에 바인딩하고 페이지를 반환하는 세 번째 테스트에서는 초당 요청 수가 거의 3/4로 줄었습니다. 이러한 시스템 리소스는 ASP.Net에서 DataSet을 DataGrid에 바인딩하는 데 사용됩니다. 페이지를 직렬화합니다.
위의 테스트를 통해 DataGrid의 바인딩 및 직렬화가 많은 시스템 리소스를 차지한다는 것을 알 수 있습니다. 시스템 성능을 향상하려면 아키텍처를 개선해야 합니다.
1. 데이터베이스에 대한 작업을 페이지에서 분리하여 독립적인 지속성 레이어에 배치합니다.
이런 방식으로 데이터는 클라이언트 측에서 DOM이나 XSLT를 통해 테이블로 표시되어 서버 측 DataGrid의 바인딩 작업을 대체하므로 서버에 대한 부담이 크게 줄어듭니다. 그리고 클라이언트는 AJAX를 통해 지속성 계층에서 데이터를 얻으므로 사용자 경험이 향상됩니다.
2. 캐시를 사용할 수 있도록 페이지와 데이터를 완전히 분리합니다.
AJAX를 적용하는 일부 페이지는 여전히 초기 데이터를 읽으므로 페이지를 캐시할 수 없습니다. 이러한 페이지는 일반적으로 일반 페이지보다 더 복잡하고 더 많은 리소스를 차지합니다. 캐시를 사용할 수 있으면 시스템 성능이 더욱 향상됩니다.
위의 두 가지 점을 통해 ASP.Net의 성능을 거의 두 배로 높일 수 있습니다.
직접 테스트하거나 샘플 www.BizStruct.cn을 방문하세요.