성능 개요

아티클
10/22/2014

업데이트: 2007년 11월

웹 사이트나 프로젝트의 성공 여부를 판단하는 데 있어 성능이 핵심 요소가 될 수 있습니다. 이 항목에서는 사이트 성능을 향상시킬 수 있는 지침을 제공할 뿐만 아니라 최선의 구현 방법을 설명하는 문서에 대한 링크도 제공합니다.

이 항목의 내용은 다음과 같습니다.

최선의 구현 방법
배경
코드 예제

최선의 구현 방법

다음은 ASP.NET 웹 사이트 성능을 위한 포괄적인 최선의 구현 방법을 설명하는 Microsoft 웹 사이트의 리소스 링크입니다.

맨 위로 이동

배경

이 단원에서는 ASP.NET 웹 응용 프로그램의 성능을 극대화하기 위해 사용할 수 있는 기술을 설명합니다. 지침은 다음 단원으로 구성되어 있습니다.

페이지 및 서버 컨트롤 처리
상태 관리
데이터 액세스
웹 응용 프로그램
코딩 작성 방법

페이지 및 서버 컨트롤 처리

다음 지침에서는 ASP.NET 페이지 및 컨트롤 작업을 효과적으로 수행하는 방법을 제안합니다.

서버로의 불필요한 라운드트립 방지 일부 경우 ASP.NET AJAX 및 부분 페이지 렌더링을 사용하면 브라우저 코드에서 전체 포스트백을 수행할 필요 없이 작업을 수행할 수 있습니다. 예를 들어 ASP.NET AJAX 기능을 사용하면 사용자 입력을 서버에 제출하기 전에 브라우저에서 사용자 입력이 유효한지 검사할 수 있습니다. 자세한 내용은 ASP.NET AJAX 개요 및 부분 페이지 렌더링 개요를 참조하십시오.
일반적으로 정보를 서버로 전달하여 확인하거나 데이터 저장소에 기록하지 않아도 되는 경우 서버로의 라운드트립을 방지하면 페이지 성능, 즉 사용자 환경이 향상됩니다.
사용자 지정 서버 컨트롤을 개발하는 경우 일부 기능을 클라이언트 스크립트로 렌더링하도록 디자인하는 것을 고려해 보십시오. 이렇게 하면 웹 서버로 정보가 전송되는 횟수를 많이 줄일 수 있습니다. 자세한 내용은 사용자 지정 ASP.NET 서버 컨트롤 개발 및 Microsoft AJAX 라이브러리를 사용하여 사용자 지정 클라이언트 스크립트 만들기를 참조하십시오.
페이지 개체의 IsPostBack 속성을 사용하여 불필요한 처리 방지 페이지가 처음 요청된 경우에만 실행되면 되는 코드인 경우 각 포스트백마다 코드가 실행되지 않게 합니다. IsPostBack 속성을 테스트하면 서버 컨트롤 이벤트에 대한 응답으로 페이지가 실행되는지 여부에 따라 조건부로 코드를 실행할 수 있습니다.
특별히 해제할 이유가 없는 경우 버퍼링을 그대로 유지 ASP.NET 웹 페이지 버퍼링을 사용하지 않으면 성능이 크게 저하됩니다. 자세한 내용은 Buffer 속성을 참조하십시오.
Server 개체의 Transfer 메서드나 페이지 간 게시를 사용하여 동일한 응용 프로그램의 ASP.NET 페이지 간에 리디렉션할 수 있습니다. 자세한 내용은 사용자를 다른 페이지로 리디렉션을 참조하십시오.

상태 관리

다음 지침에서는 효율적인 상태 관리 방법을 제안합니다.

필요한 경우에만 서버 컨트롤 뷰 상태 저장 뷰 상태를 사용하면 코드를 작성하지 않아도 서버 컨트롤에서 라운드트립에 대한 속성 값을 다시 채울 수 있습니다. 그러나 뷰 상태는 숨겨진 폼 필드로 서버에 전달되거나 서버로부터 전달되기 때문에 성능과 페이지 크기에 영향을 줍니다. 모든 라운드트립에서 서버 컨트롤을 데이터에 바인딩하는 경우 컨트롤의 값이 데이터 바인딩 중에 새 값으로 바뀌기 때문에 저장된 뷰 상태는 유용하지 않습니다. 이 경우 뷰 상태를 사용하지 않으면 처리 시간이 단축되고 페이지 크기가 줄어듭니다.

기본적으로 뷰 상태는 모든 서버 컨트롤에서 사용됩니다. 컨트롤에서 뷰 상태를 사용하지 않으려면 다음 예제에서와 같이 컨트롤의 EnableViewState 속성을 false로 설정합니다.
```
<asp:datagrid EnableViewState="false" datasource="..." 
   />
```
다음 예제에서와 같이 @ Page 지시문을 사용하여 페이지의 뷰 상태를 비활성화할 수도 있습니다.
```
<%@ Page EnableViewState="false" %>
```
이것은 페이지에 포스트백 처리가 필요하지 않을 때 유용합니다.

참고:

EnableViewState 특성은 @ Control 지시문에도 지원되며, 사용자 정의 컨트롤에 대한 뷰 상태의 사용 여부를 지정하는 데 사용됩니다.

페이지에 대한 뷰 상태의 크기를 분석하려면 @ Page 지시문에서 trace="true"를 설정하여 페이지 추적을 사용합니다. 추적 출력에서 Control Hierarchy 테이블의 Viewstate 열을 확인합니다. 자세한 내용은 ASP.NET 추적 개요를 참조하십시오.
필요한 경우를 제외하고 뷰 상태 암호화를 사용하지 않음 뷰 상태 암호화는 사용자가 숨겨진 뷰 상태의 폼 필드에서 뷰 상태 값을 읽을 수 없도록 합니다. 예를 들어 페이지에 레코드의 업데이트를 제어하기 위해 DataKeyNames 속성의 식별자 필드를 유지하는 GridView 컨트롤이 포함된 경우 뷰 상태를 암호화할 수 있습니다. 식별자는 사용자에게 노출되면 안 되므로 뷰 상태를 암호화하는 것이 좋습니다. 그러나 암호화는 초기화 과정에서 일정하게 성능을 저하시키며 암호화되는 뷰 상태의 크기에 따라 추가로 성능이 저하됩니다. 암호화는 페이지가 로드될 때마다 수행됩니다. 따라서 페이지가 처음 요청될 때나 각 포스트백마다 동일한 성능 저하가 발생합니다.

참고:
EnableViewState 특성은 @ Control 지시문에도 지원되며, 사용자 정의 컨트롤에 대한 뷰 상태의 사용 여부를 지정하는 데 사용됩니다.

사용하지 않는 경우 세션 상태 비활성화 페이지의 세션 상태를 비활성화하려면 다음 예제와 같이 @ Page 지시문의 EnableSessionState 특성을 false로 설정합니다.

<%@ Page EnableSessionState="false" %>

참고:
페이지에서 세션 변수에 액세스만 하고 이를 만들거나 수정하지 않는 경우에는 @ Page 지시문의 EnableSessionState 특성을 ReadOnly로 설정합니다.

ASP.NET 웹 서비스 메서드에 대해 세션 상태를 비활성화할 수도 있습니다. 자세한 내용은 ASP.NET 응용 프로그램 서비스 개요를 참조하십시오.

응용 프로그램의 세션 상태를 비활성화하려면 응용 프로그램에 대한 Web.config 파일의 SessionState 섹션에서 Mode 특성을 Off로 설정합니다.

<sessionState mode="Off" />

응용 프로그램에 적절한 세션 상태 공급자 선택 ASP.NET에서는 응용 프로그램의 세션 데이터를 저장할 수 있는 여러 가지 방법을 제공합니다. 여기에는 in-process 세션 상태, Windows 서비스인 out-of-process 세션 상태 및 SQL Server 데이터베이스의 out-of-process 세션 상태가 포함됩니다. 사용자 지정 세션 상태 공급자를 만들어 지정한 데이터 저장소에 세션 데이터를 저장할 수도 있습니다. 각 방법마다 이점이 있지만 in-process 세션 상태가 가장 빠른 방법입니다. 적은 양의 데이터에만 세션 상태를 사용하는 경우에는 in-process 공급자를 사용하는 것이 좋습니다. out-of-process 세션 상태 옵션은 다중 프로세서 또는 여러 대의 컴퓨터에 응용 프로그램을 확장하거나 서버 또는 프로세스가 다시 시작될 때 세션 데이터를 유지하려는 경우 사용합니다. 자세한 내용은 ASP.NET 세션 상태 개요를 참조하십시오.

데이터 액세스

다음 지침에서는 응용 프로그램의 효율적인 데이터 액세스 방법을 제안합니다.

데이터 액세스를 위해 SQL Server 및 저장 프로시저 사용 고성능의 확장 가능한 웹 응용 프로그램을 만들려면 SQL Server를 데이터 저장소로 사용하는 것이 좋습니다. 관리되는 SQL Server 공급자를 사용할 때 가능한 경우 SQL 명령 대신 컴파일된 저장 프로시저를 사용하면 성능을 더욱 향상시킬 수 있습니다. 자세한 내용은 매개 변수 구성(ADO.NET)를 참조하십시오.
앞으로만 이동 가능한 빠른 데이터 커서에 대해 SqlDataReader 클래스 사용 SqlDataReader 클래스는 SQL Sever 데이터베이스에서 검색한 앞으로만 이동 가능한 읽기 전용 데이터 스트림을 만듭니다. SqlDataReader 클래스는 SQL Server의 네이티브 네트워크 데이터 전송 형식을 사용하여 데이터베이스 연결에서 직접 데이터를 읽습니다. 가능한 경우 DataSet 클래스보다 나은 성능을 제공하는 SqlDataReader 클래스를 사용하십시오. 예를 들어 SqlDataSource 컨트롤에 데이터 컨트롤을 바인딩하는 경우 DataSourceMode 속성을 DataReader로 설정하면 성능이 향상됩니다. 하지만 데이터 판독기에서는 DataSet 모드에서 지원하는 기능보다 적은 기능을 지원합니다. SqlDataReader 클래스는 서버 컨트롤을 바인딩할 수 있는 IEnumerable 인터페이스를 구현합니다. 자세한 내용은 SqlDataReader 클래스 및 ASP.NET을 사용하여 데이터 액세스을 참조하십시오.
가능한 경우 항상 데이터와 페이지 출력 캐시 각 페이지 요청마다 페이지나 데이터를 동적으로 계산하지 않아도 되는 경우 ASP.NET 캐싱을 사용합니다. 가능한 경우 페이지와 데이터 요청을 캐싱이 가능하도록 디자인합니다. 특히 많은 트래픽이 예상되는 경우 캐싱이 필요합니다. 캐시를 적절하게 사용하면 .NET Framework의 다른 기능을 사용하는 것보다 사이트 성능을 훨씬 향상시킬 수 있습니다.

ASP.NET 캐싱을 사용할 경우 다음 지침을 따릅니다. 첫째, 캐시된 각 항목은 서버 메모리를 사용하므로 지나치게 많은 항목을 캐시하지 마십시오. 예를 들어 다시 계산되기 쉽거나 사용 빈도가 낮은 항목은 캐시하지 않아야 합니다. 두 번째, 캐시된 항목의 만료 기간을 짧게 지정하지 마십시오. 항목의 만료 기간이 너무 짧으면 정리 코드와 가비지 수집기의 작업량이 늘어날 수 있습니다. ASP.NET Applications 성능 개체에 연결된 Cache Total Turnover Rate 성능 카운터를 사용하여 만료되는 항목으로 인한 캐시 회전율을 모니터링할 수 있습니다. 특히 항목이 만료되기도 전에 제거되는 경우처럼 회전율이 높으면 문제가 있는 것입니다. 이런 경우를 메모리 압력이라고도 합니다.

페이지 출력과 데이터 요청을 캐시하는 방법에 대한 자세한 내용은 ASP.NET 캐싱 개요를 참조하십시오.
SQL 캐시 종속성을 적절하게 사용 SQL Server에서 데이터를 캐시할 수 있도록 ASP.NET에서는 사용 중인 SQL Server의 버전에 따라 테이블 기반 폴링과 쿼리 알림을 모두 지원합니다. 테이블 기반 폴링은 모든 버전의 SQL Server에서 지원됩니다. 테이블 기반 폴링에서는 테이블에 변경된 데이터가 있으면 테이블에 종속된 모든 캐시 항목이 무효화됩니다. 이로 인해 캐시 회전율이 불필요하게 늘어날 수 있습니다. 내용이 자주 변경되는 테이블에는 테이블 기반 폴링을 사용하지 않는 것이 좋습니다. 예를 들어 테이블 기반 폴링은 내용이 자주 변경되지 않는 카탈로그 테이블에 사용하는 것이 좋으며, 자주 업데이트되는 주문 테이블에는 사용하지 않는 것이 좋습니다.

쿼리 알림은 SQL Server 2005 이상 버전에서 지원됩니다. 쿼리 알림은 SQL 쿼리를 사용하여 대상 행 집합의 변경 사항을 검색합니다. 따라서 테이블이 변경될 때 전송되는 알림의 수가 줄어듭니다. 쿼리 알림을 사용할 경우 테이블 기반 폴링을 사용할 때보다 나은 성능을 얻을 수 있지만 수천 개의 쿼리로 확장하는 것은 불가능합니다.

SQL 캐시 종속성에 대한 자세한 내용은 연습: SQL Server에 ASP.NET 출력 캐싱 사용 및 ASP.NET에서 SqlCacheDependency 클래스를 사용한 캐싱을 참조하십시오.
UI(사용자 인터페이스) 페이징 및 정렬 대신 데이터 소스 페이징 및 정렬 사용 DetailsView 및 GridView와 같은 데이터 컨트롤의 UI 페이징 기능은 ICollection 인터페이스를 지원하는 모든 데이터 소스 개체에 사용할 수 있습니다. 각 페이징 작업에서 데이터 컨트롤은 데이터 소스에 전체 데이터 컬렉션을 쿼리하여 표시할 행을 선택하고 나머지 데이터는 무시합니다.

데이터 소스 컨트롤에서 DataSourceView를 구현하고 CanPage 속성에서 true를 반환하는 경우 데이터 컨트롤에서는 UI 페이징 대신 데이터 소스 페이징을 사용합니다. 이 경우 데이터 컨트롤은 표시할 각 페이지에 필요한 행만 요청합니다. 따라서 데이터 소스 페이징은 UI 페이징보다 효율적입니다. 표준 ASP.NET 컨트롤 중에서 ObjectDataSource 및 LinqDataSource 데이터 소스 컨트롤만 데이터 소스 페이징을 지원합니다. 다른 데이터 소스 컨트롤에서 데이터 소스 페이징을 사용하려면 사용하려는 데이터 소스 컨트롤에서 상속하여 동작을 수정해야 합니다.
**동시성 제어에 LinqDataSource 컨트롤과 Timestamp 열 사용 **SQL Server 데이터베이스 테이블에 Timestamp 열(SQL Server 데이터 형식)이 포함되지 않는 경우 LinqDataSource 컨트롤에서는 웹 페이지에 원래 데이터 값을 저장하여 데이터 동시성을 확인합니다. LINQ to SQL에서는 데이터를 업데이트하거나 삭제하기 전에 데이터베이스와 원래 값을 비교하여 확인합니다. 데이터 레코드에 많은 열이나 큰 열 값이 있는 경우 이 방법으로 큰 웹 페이지를 만들 수 있습니다. 또한 페이지에 표시하고 싶지 않은 데이터가 레코드에 있는 경우 보안 위험을 나타낼 수 있습니다. 데이터베이스 테이블에 Timestamp 열이 있는 경우에는 LinqDataSource 컨트롤에서 나중에 비교할 수 있도록 타임스탬프 값만 저장합니다. LINQ to SQL은 원래 타임스탬프 값이 테이블의 현재 타임스탬프 값과 일치하는지 확인하여 데이터 일관성을 확인할 수 있습니다. 타임스탬프에 대한 자세한 내용은 MSDN 웹 사이트에서 timestamp(Transact-SQL)를 참조하십시오.

**이벤트 유효성 검사의 보안상 이점과 성능 비용 간의 균형 **System.Web.UI.WebControls 및 System.Web.UI.HtmlControls 클래스에서 파생된 컨트롤에서는 이벤트가 발생한 지점이 컨트롤에서 렌더링한 사용자 인터페이스인지 여부를 확인할 수 있습니다. 이를 통해 컨트롤이 스푸핑된 이벤트 알림에 응답하는 것을 막을 수 있습니다. 예를 들어 이벤트 유효성 검사를 사용하면 악의적인 사용자가 DetailsView 컨트롤에서 기본적으로 지원하지 않는 Delete 호출을 수행하여 데이터를 삭제하지 못하도록 방지할 수 있습니다. 이벤트 유효성 검사는 성능을 다소 저하시킵니다. EnableEventValidation 구성 요소 및 RegisterForEventValidation 메서드를 사용하여 이벤트 유효성 검사를 제어할 수 있습니다. 유효성 검사로 인한 성능 비용은 페이지의 컨트롤 수에 좌우되며 몇 퍼센트의 성능 차이를 발생시킵니다.

보안 정보:
이벤트 유효성 검사는 해제하지 않는 것이 좋습니다. 이벤트 유효성 검사를 비활성화하기 전에 응용 프로그램에 의도하지 않은 영향을 주는 포스트백이 생성될 가능성이 없는지 확인해야 합니다.

**SqlDataSource 컨트롤의 캐싱, 정렬 및 필터링 사용 **SqlDataSource 컨트롤의 DataSourceMode 속성이 DataSet으로 설정되면 SqlDataSource 컨트롤에서 쿼리의 결과 집합을 캐시할 수 있습니다. 그러면 SqlDataSource 컨트롤의 필터링 및 정렬 작업에 캐시된 데이터를 사용할 수 있습니다. 전체 데이터 집합을 캐시하고 FilterExpression 및 SortParameterName 속성을 사용하여 정렬 및 필터링을 사용하는 경우 응용 프로그램이 더 빨리 실행될 수 있습니다. 이 경우 데이터 소스 컨트롤에서 사용자가 UI의 데이터를 정렬하거나 필터링할 때마다 데이터베이스에 액세스하는 Where 및 Sort By 절이 있는 SQL 쿼리를 실행할 필요가 없습니다.

웹 응용 프로그램

다음 지침에서는 하나의 전체 작업으로서 웹 응용 프로그램의 효율성을 높이는 방법을 제안합니다.

사이트 미리 컴파일 웹 응용 프로그램은 ASP.NET 웹 페이지 같은 리소스를 처음으로 요청할 때 일괄 컴파일됩니다. 응용 프로그램에 컴파일된 페이지가 전혀 없으면 디스크와 메모리를 더 효율적으로 사용하기 위해 디렉터리의 모든 페이지가 한꺼번에 일괄적으로 컴파일됩니다. ASP.NET 컴파일 도구(Aspnet_compiler.exe)를 사용하여 웹 응용 프로그램을 미리 컴파일할 수 있습니다. 현재 위치에서 곧바로 컴파일하는 경우 컴파일 도구는 ASP.NET 런타임을 호출하여 사용자가 웹 사이트에서 페이지를 요청할 때와 동일한 방식으로 사이트를 컴파일합니다. 웹 응용 프로그램을 미리 컴파일하여 UI 태그를 유지하거나, 페이지를 미리 컴파일하여 소스 코드가 변경되지 않도록 할 수 있습니다. 자세한 내용은 방법: ASP.NET 웹 사이트 미리 컴파일을 참조하십시오.
디버그 모드 비활성화 프로덕션 응용 프로그램을 배포하거나 성능 측정을 수행하기 전에는 항상 디버그 모드를 비활성화해야 합니다. 디버그 모드가 활성화되어 있으면 응용 프로그램의 성능이 저하될 수 있습니다. 디버그 모드 설정 방법에 대한 자세한 내용은 ASP.NET 구성 파일 편집을 참조하십시오.
웹 서버 컴퓨터 및 특정 응용 프로그램의 구성 파일 조정 ASP.NET의 기본 구성은 가장 광범위한 기능 집합과 가장 일반적인 시나리오를 수용합니다. 사용하는 기능에 따라 일부 기본 구성 설정을 변경하여 응용 프로그램 성능을 향상시킬 수 있습니다. 다음 목록에는 고려해야 할 구성 변경 사항이 나와 있습니다.
- 필요한 응용 프로그램에 대해서만 인증 활성화 기본적으로 ASP.NET 응용 프로그램의 인증 모드는 Windows 또는 통합 NTLM입니다. 대부분의 경우 Machine.config 파일의 인증을 비활성화하고 필요한 응용 프로그램에 대해서만 Web.config 파일에서 인증을 활성화하는 것이 좋습니다.
- 요청 및 응답 인코딩 설정에 맞게 응용 프로그램 구성 ASP.NET 기본 인코딩은 UTF-8입니다. 응용 프로그램에서 ASCII 문자만 사용하는 경우 응용 프로그램을 ASCII로 구성하면 성능이 다소 향상됩니다.
- 응용 프로그램에 대한 AutoEventWireup 비활성화 Web.config 파일에서 AutoEventWireup 특성을 false로 설정하면 페이지에서 이름 일치를 기반으로 페이지 이벤트를 메서드에 바인딩하지 않습니다(예: Page_Load). 따라서 페이지 성능이 약간 향상될 수 있습니다. 페이지 이벤트를 처리하는 데는 다음 두 전략 중 하나를 사용합니다. 첫 번째 전략은 메서드를 재정의하는 것입니다. 예를 들어 Page 개체의 OnLoad 메서드를 재정의하여 페이지 로드 이벤트에 대한 코드를 작성할 수 있습니다. 이 경우 모든 이벤트가 발생하도록 기본 메서드를 호출해야 합니다. 두 번째 전략은 Visual Basic의 Handles 키워드나 C#의 대리자 연결을 사용하여 페이지 이벤트에 바인딩하는 것입니다.
- 요청 처리 파이프라인에서 사용하지 않는 모듈 제거 기본적으로 모든 기능은 웹 서버 컴퓨터의 Machine.config 파일에 있는 HttpModules 노드에서 활성화되어 있습니다. 응용 프로그램에 사용되는 기능에 따라 요청 파이프라인에서 사용되지 않는 모듈을 제거하여 약간의 성능 개선 효과를 얻을 수 있습니다. 각 모듈 및 기능을 검토하고 사용자 요구에 맞게 사용자 정의합니다. 예를 들어 응용 프로그램에서 세션 상태와 출력 캐싱을 사용하지 않는 경우 HttpModules 목록에서 해당 기능의 모듈을 제거합니다.
IIS 5.0에서 웹 응용 프로그램을 out-of-process로 실행 기본적으로 IIS 5.0의 ASP.NET에서는 out-of-process 작업자 프로세스를 사용하여 요청을 처리합니다. 이 기능은 처리 속도를 높이기 위해 조정되었습니다. Out-of-process 작업자 프로세스에서 ASP.NET을 실행하면 많은 장점이 있고 다양한 기능을 사용할 수 있으므로 프로덕션 사이트에 권장됩니다.
프로세스를 정기적으로 재생 안정성 및 성능 측면을 모두 고려하여 프로세스를 정기적으로 재생해야 합니다. 오랜 기간 동안 리소스에 메모리 누수와 버그가 있으면 웹 서버 처리량에 영향을 줄 수 있으며 재생 프로세스는 메모리에서 이러한 유형의 문제를 제거합니다. 그러나 작업자 프로세스를 중지하고 페이지를 다시 로드한 후 리소스 및 데이터를 다시 얻는 비용이 재생으로 인한 이점보다 클 수 있으므로 자주 재생해야 하는 경우 이 점을 고려하여 균형을 맞춰야 합니다.

Windows Server 2003과 IIS 6.0에서 실행되는 ASP.NET 웹 응용 프로그램의 경우 ASP.NET에서 IIS 6.0 프로세스 모델 설정을 사용하므로 프로세스 모델을 조정할 필요가 없습니다.

응용 프로그램에 맞게 작업자 프로세스별 스레드 수 설정 ASP.NET의 요청 아키텍처에서는 요청을 실행하는 스레드 수와 사용 가능한 리소스 간의 균형을 맞추려고 시도합니다. 이 아키텍처는 사용 가능한 CPU 성능만큼만 동시 실행 요청 수를 허용합니다. 이 기술을 가리켜 thread gating이라고 합니다. 그러나 thread-gating 알고리즘이 제대로 적용되지 않는 상황도 있습니다. ASP.NET Applications 성능 개체에 연결된 Pipeline Instance Count 성능 카운터를 사용하여 Windows 성능 모니터에서 thread gating을 모니터링할 수 있습니다.

ASP.NET 웹 페이지에서 데이터베이스에 액세스하거나 ASP.NET 웹 서비스 요청을 처리할 때와 같이 외부 리소스를 호출할 경우 일반적으로 외부 리소스가 응답할 때까지 페이지 요청이 중지됩니다. 따라서 CPU에서 다른 스레드를 처리할 수 있습니다. 다른 요청이 처리를 기다리고 있을 때 스레드 풀에서 스레드가 회수되면 대기하고 있는 요청이 처리되기 시작합니다. 결과적으로 ASP.NET 작업자 프로세스나 응용 프로그램 풀에서 동시에 실행되는 요청 수와 대기 중인 스레드 수가 많아질 수 있습니다. 이로 인해 웹 서버 처리가 방해를 받고 성능이 저하될 수 있습니다.

성능에 미치는 이러한 효과를 줄이기 위해 프로세스의 스레드 수를 제한할 수 있습니다. 이 작업을 수행하려면 Machine.config 파일의 processModel 섹션에서 MaxWorkerThreads 및 MaxIOThreads 특성을 변경합니다.

참고:
작업자 스레드는 ASP.NET 요청 처리를 위한 것이며, IO 스레드는 파일, 데이터베이스 또는 ASP.NET 웹 서비스의 데이터를 제공하는 데 사용됩니다.

이 프로세스 모델 특성에 할당되는 값은 처리 중인 CPU당 각 스레드 형식의 최대 수를 나타냅니다. 프로세서가 두 개인 컴퓨터일 경우 최대 수는 설정 값의 두 배입니다. 프로세서가 네 개인 컴퓨터에서는 설정 값의 4배입니다. 기본 설정은 프로세서가 하나나 두 개인 컴퓨터에는 적합하지만 셋 이상의 프로세서가 있는 컴퓨터의 프로세스에서 100개 내지 200개의 스레드를 처리하는 경우 성능이 저하될 수 있습니다. 프로세스에 지나치게 많은 스레드가 있으면 성능이 느려질 수 있습니다. 즉, 서버에서 추가적인 컨텍스트 전환을 수행해야 하므로 운영 체제가 요청을 처리하기보다 스레드를 유지하는 데 CPU 사이클을 소비하게 됩니다. 적절한 스레드 개수는 응용 프로그램 성능 테스트를 통해 결정할 수 있습니다.

외부 리소스를 많이 사용하는 응용 프로그램의 경우 다중 프로세서 컴퓨터에서 웹 가든 사용 ASP.NET 프로세스 모델은 CPU당 하나씩, 프로세서 선호도가 CPU로 설정된 여러 프로세스에 작업을 분산하여 다중 프로세서 컴퓨터에서 확장을 가능하게 합니다. 이 기술을 웹 가든이라고도 합니다. 웹 응용 프로그램이 외부 리소스를 많이 사용하는 경우 웹 가든을 통해 이점을 얻을 수 있습니다. 예를 들어 응용 프로그램에서 데이터베이스 서버를 사용하거나 외부 종속성이 있는 COM 개체를 호출하는 경우 이점을 얻을 수 있습니다. 그러나, 프로덕션 웹 사이트에서 웹 가든을 사용하기 전에 웹 가든이 설정된 상태에서 웹 응용 프로그램의 성능을 테스트해야 합니다.

코딩 작성 방법

다음 지침에서는 효율적인 코드 작성 방법을 제안합니다.

코드에서 예외 사용 자제 예외는 성능을 상당히 저하시키므로 예외를 일반 프로그램 흐름을 제어하는 방법으로 사용하는 것을 자제해야 합니다. 가능하다면 예외를 발생시킬 수 있는 조건을 검색하고 처리하는 논리를 코드에 포함합니다. 코드에서 이러한 조건을 검색하는 일반 시나리오에는 null을 확인하거나, 숫자 값으로 구문 분석되는 문자열을 확인하거나, 수치 연산을 적용하기 전에 특정 값을 확인하는 것 등이 있습니다. 다음 예제에서는 예외를 유발할 수 있는 코드와 조건을 테스트하는 대체 코드를 보여 줍니다. 두 예제의 결과는 같습니다.
```
// This is not recommended.
try {
   result = 100 / num;
}
catch (Exception e) {
  result = 0;
}

// This is preferred.
if (num != 0)
   result = 100 / num;
else
  result = 0;
```
```
' This is not recommended.
Try
   result = 100 / num
Catch (e As Exception)
  result = 0
End Try

' This is preferred.
If Not (num = 0)
   result = 100 / num
Else
  result = 0
End If
```