http://weblogs.asp.net/haroonwaheed/ASP.NET-Performance-Tips 페이지의 번역, 요약
Remove Unused HTTP Modules (불필요한 HTTP Module의 삭제)
HTTP Modules 은 사용자로부터 각각의 Request를 전달 받을 때 마다 Intercept 를 하게 된다. 그리고 생각보다 많은 Module들이 선언되어 있는 경우가 종종 있는데, 이런 경우에는 불필요하게 선언되어있는 모듈들을 솎아내면 성능 향상에 도움을 준다.
다음 항목 : <Compilation debug="true" /> 을 사용하지 말 것
Product 레벨로의 배포를 할 때 정말 쉽게 볼 수 있는 이 구문은 성능 하락에 엄청난 영향을 준다. 이는 ASP.NET 페이지의 컴파일 시간을 더 걸리도록 하고 디버깅을 위해 코드 실행이 더 느려지게 된다. 또한 더 많은 메모리를 사용하게 될 뿐만 아니라 스크립트나 이미지 캐싱을 사용하지 않게 된다. 이 항목을 배포시에 추가하지 않거나 Production 인스턴스에서 machine.config 에 <deployment retail="true" /> 를 추가하는 방법을 사용한다.
Process Model Optimization
ASP.NET에서는 프로세스 수준에서의 설정을 할 수 있는데 보통은 자동으로 설정되어 있는 경우가 많다. 이런 설정 정보들을 다루는 것을 통해서 더 나은 성능을 보여줄 수도 있으므로 해당 값들을 기억해 두자.
- maxWorkerThreads : 기본은 프로세스당 20. CPU에 많은 영향을 주지 않고 더 많은 데이터베이스 요청을 할 수 있거나 성능을 더 높이는데 도움을 준다.
- maxIOThreads : 기본은 프로세스당 20. 초당 얼마나 많은 IO 요청을 처리하는 지에 대한 수치인데 IO Resource 가 충분하다면 이것을 높여 성능을 개선한다.
- memoryLimit : 기본은 60%, 해당 인스턴스가 오직 웹 어플리케이션용도로만 사용한다면 이 수치를 올려서 더 나은 성능을 볼 수 있다.
- connectionManagement : 서버에 최대 병렬 커넥션을 얼마나 둘지에 대한 설정정보이다. 웹 어플리케이션이 외부에 접속하는 경우가 많다면 이 수치를 높이는 것이 좋다.
Enable Buffering : 버퍼를 사용하자
버퍼링은 명확하게 선언하지 않으면 기본적으로는 사용하는 상태이다. 그러나 명시적으로 이 버퍼를 사용하지 않으면 31KB 사이즈의 버퍼로 전달해주던 데이터를 캐릭터 단위로 전송해주기 때문에 worker 프로세스와 IIS 간의 데이터 전송이 잩아져서 성능에 영향을 준다. 가능하다면 아래와 같이 page 항목에 buffer 를 사용하도록 수정하는 것이 좋다.
Caching : 캐싱
캐싱은 아주 드라마틱 하게 애플리케이션의 성능향상에 도움을 준다. 기본적으로 서버에 대한 부하를 줄여주고 웹 요청으로부터 매번 결과물을 생성해 줄 필요없이 캐싱된 컨텐츠를 전달해주는 것으로 대신할 수 있다. ASP.NET 에는 두 가지 형태의 캐싱이 존재한다. 하지만 캐싱은 그 방법과 전략에 따라서 차이가 있으니 적절하게 잘 사용하는 것이 좋다.
- Output Cache : 동적인 페이지나 사용자 컨트롤 정보에 대해서 캐싱하는 것을 말한다. 캐싱된 버전의 페이지가 유효하다면 요청 코드마다 실행되지 않도록 함.
- Data Cache : 애플리케이션 오브젝트들이나 데이터셋과 같은 정보들을 서버 메모리에 저장하도록 하여 요청마다 해당 정보들을 재 생성하지 않도록 함.
Kernel Cache : 커널 캐시
이는 IIS 6 버전 이상에서만 사용할 수 있다. 보통은 Output Cache 의 경우에는 ASP.NET을 통해서 생성하고 IIS가 받아서 End-User에게 전달하는 방법이지만, 이는 같은 요청은 한 경우에 ASP.NET을 거치지 않고 바로 IIS가 가지고 있는 캐시된 컨텐츠를 전달해주는 방법이다.
Avoid using Response.Redirect : Response.Redirect 메소드 사용을 피할 것
결론적으로는 Server.Transfer 를 사용하는 방법으로 사용하라는 것. 이는 Response 에서는 사용자의 요청에 따라 예약된 경로로 리다이렉트 시키는 과정에서 또 다른 사용자 요청을 생성하도록 하는 형태이기 때문이다. Response.Redirect 는 서버 내부의 인증과정이나 권한 여부 확인을 하는 용도로 사용할 때만 쓰는 것이 좋다.
Avoid using Server-Side Validation : 서버사이드 유효성 검사를 피할 것
클라이언트에서 입력된 값을 서버사이드에서만 처리하는 경우가 있는데 기본적인 유효성 검사들은 클라이언트에서 수행하는 것이 더욱 성능면에서 우수하다.
Avoid using DataBinder.Eval Calls : DataBinder.Eval 메소드의 사용을 피할 것
대신 Container.DataBind 를 사용하는 것이 좋다. DataBinder.Eval 은 그리드나 반복문을 사용할 때 Container 에 비해서 성능이 낮다. DataBinder.Eval 은 Reflection 을 사용하여 Argument 를 검사하는 것이 추가로 있기 때문이다.
Avoid using Page.DataBind
정말 필요하다고 느껴지는 것이 아니라면 사용하지 않도록 한다.
ViewState Optimization
ViewState 는 서버 컨트롤에 의해서 사용이 되는데 PostBack 이 일어난 이후에 다시 전의 상태 정보들을 얻기 위해서 쓴다. 하지만 많은 양의 정보들을 보관하는데는 적합하지 않아서 보관이 필요한 경우에만 사용하도록 한다. ASP.NET 은 ViewState 에 저장하게 될 모든 오브젝트들과 컨트롤들을 Serialize 하게 되고 이것들이 페이지 사이즈를 증가시키는 원인이 되고 네트워크 트래픽을 증가하도록 만든다. 따라서 다음과 같은 상황에는 ViewState 를 Disabled 시키는 것이 좋다.
- 페이지를 PostBack 할 필요가 없는 경우
- 컨트롤에 데이터 소스를 바인딩하지 않는 경우, OnClick 과 같은 서버 이벤트를 사용하지 않는 경우
- PostBack 이 일어날 때 마다 컨트롤을 새로 생성해줘야 하는 경우
Save or Compress ViewState
ViewState 를 반드시 사용해야 하는 경우에 해당이 된다. ViewState 에 포함된 데이터들에 대한 다운로드 시간을 줄이기 위해서 압축하거나 저장하는 방식을 사용한다. Page 클래스에서 이를 위한 기능을 제공하는데 LoadPageStateFromPersistenceMedium(), SavePageStateToPersistenceMedium(object ViewState) 이 두 가지 메소드가 유용하게 사용이 된다. ViewState 를 압축하거나 저장하는 방법이다.
Use HTTP Compression
페이지 사이즈 커서 눈의 띄게 중단 현상이 있다면 HTTP Compression 을 고려해볼 필요가 있다. 이는 IIS에서 제공해주는 기능인데 사용자에게 압축된 데이터를 전달해주는 기술이다. 반대로 사용자의 브라우저는 이 압축을 풀어서 사용자에게 보여준다. 최근에 나온 브라우저들은 모두 이 기능을 제공하고 있다.
Data Paging / Sorting
많은 양의 데이터를 한꺼번에 보여주는 것 보다 일부를 페이징, 정렬하여 보여주는 것이 성능이 낫다.
Connection Pooling
데이터베이스의 Connection을 생성하는 것 자체가 프로세스 리소스에 영향을 준다. 때문에 Connection Pool 은 이 Connection들을 재사용할 수 있도록 도와준다. 아래는 Connection Pooling 을 사용하는데서 오는 이점이다.
- Connection 리킹을 방지 : 연결을 생성하지만 닫지 않아서 생기는 문제는 예방
- 여러 연결이 같은 ConnectionString 을 사용할 수 있도록 도와줌.
- SQL Server 나 .NET CLR Data 를 통해서 모니터링이 가능함.
- 새로운 Connection 을 생성하는 것을 최대한 억제하고, Connection 을 줄이는 것은 최대한 빠르게 하여 리소스를 절약할 수 있도록 도와줌.
- 각각의 기능마다 각각의 Connection 을 사용하도록 함.
- Connection 을 닫으면서 트랜잭션에 대한 마무리도 수행함.
- Connection Pool 에 적어도 하나의 Connection 은 유지하도록 도와줌.
Avoid Multiple Database Access : 여러번 데이터베이스에 접근하는 것을 피하라
한 요청을 통해서 데이터 베이스에 여러 번 접근하는 것을 피하라. Stored Procedure 를 통해서 수행하고 결과를 조합하는 방법이 더 좋다.
Use DataReader instead of Data : DataSet 보다 Data Reader 를 사용하라
데이터 노출을 위한 것이라면 DataReader 를 사용하는 것이 더 좋다. 이는 조회 전용이기 때문에 아주 최적화된 형태로 데이터를 지니고 있다. DataSet 은 비연결 방식으로 데이터를 서버 메모리에 저장하는 방식으로 서버 자원을 사용하는 형태이기 때문이다. DataSet 은 가공이 필요한 경우에만 사용한다.
