ASP.Net 응용 프로그램 성능을 향상시키는 10가지 방법
저자：Eve Cole
업데이트 시간：2009-06-30 15:49:49
이 기사에서는 다음 내용을 설명합니다.
asp.net 응용 프로그램 성능 향상에 대해 일반적으로 알려진 오해 asp.net 응용 프로그램 성능을 향상시키는 데 유용한 팁
Asp.net 애플리케이션을 사용한 데이터베이스 운영에 대한 권장 사항
Asp.net의 캐싱 및 백그라운드 처리
요즘에는 ASP.NET 웹 응용 프로그램을 작성하는 것이 매우 간단해졌으며 많은 프로그래머는 좋은 성능을 갖춘 응용 프로그램을 구축하는 데 시간을 낭비하고 싶어하지 않습니다. 이 기사에서는 웹 애플리케이션의 성능을 향상시키는 10가지 방법에 대해 설명합니다. ASP.NET 응용 프로그램은 웹 응용 프로그램의 하위 집합일 뿐이므로 논의를 ASP.NET 응용 프로그램으로 제한하지 않겠습니다. 또한 이 기사는 웹 애플리케이션 성능 향상에 대한 완전한 가이드를 제공할 수 없습니다. 이를 위해서는 책 한 권의 분량이 필요하기 때문입니다. 이 문서는 웹 애플리케이션 성능을 향상시키기 위한 좋은 출발점만을 제공합니다. (남은 것은 스스로 천천히 공부하는 것 뿐이다.)
업무 외적으로는 암벽등반을 자주 갑니다. 매번 암벽등반을 하기 전에 암벽등반 루트 지도를 검토하고, 이전에 성공한 암벽등반자들의 조언을 읽습니다. 그들의 성공적인 경험이 필요하기 때문입니다. 마찬가지로, 성능 문제가 있는 프로그램을 수정해야 하거나 고성능 웹사이트를 개발해야 하는 경우에도 고성능 웹 애플리케이션을 작성하는 방법을 배워야 합니다.
저의 개인적인 경험은 주로 Microsoft asp.net 그룹에서 프로그램 관리자로 일하고, www.asp.net 웹 사이트를 운영 및 관리하고, asp.net 포럼의 통합 및 업그레이드 버전인 Community Server 개발을 지원한 것입니다. , .Text 및 nGallery 소프트웨어). 이런 경험들이 나에게 도움이 될 것 같아요.
애플리케이션을 서로 다른 논리적 계층으로 나누는 것을 생각할 수도 있습니다. 가장 일반적으로 사용되는 아키텍처 모델인 3계층 물리적 아키텍처 또는 N계층 아키텍처에 대해 들어보셨을 것입니다. 이는 실행을 위해 다양한 프로그램 기능을 다양한 하드웨어에 물리적으로 할당합니다. 이런 방식으로 애플리케이션의 성능을 향상시키려면 일부 하드웨어를 추가하면 목표를 달성할 수 있습니다. 이 방법을 사용하면 애플리케이션의 성능이 향상될 수 있지만 이 방법을 사용하지 않는 것이 좋습니다. 따라서 가능하면 ASP.NET 페이지와 페이지에서 사용하는 구성 요소를 응용 프로그램에 넣어야 합니다.
분산 배포와 웹 서비스 또는 원격 사용으로 인해 애플리케이션 성능이 20% 이상 저하됩니다.
데이터 계층은 약간 다릅니다. 독립적으로 배포하고 별도의 하드웨어를 사용하여 실행하는 것이 좋습니다. 그럼에도 불구하고 데이터베이스는 여전히 애플리케이션 성능의 병목 현상을 일으키고 있습니다. 따라서 프로그램을 최적화하고 싶을 때 가장 먼저 염두에 두어야 할 부분은 데이터 계층을 최적화하는 것입니다.
성능 문제를 일으키는 애플리케이션 영역을 수정하기 전에 문제를 일으키는 프로그램이 제대로 작동하지 않는지 확인해야 합니다. 성능 프로파일러는 애플리케이션에서 시간이 얼마나 걸리는지 찾는 데 매우 유용합니다. 우리가 직관적으로 느낄 수 없는 곳이다.
이 문서에서는 두 가지 유형의 성능 최적화에 대해 설명합니다. 하나는 asp.net의 캐시를 사용하는 것과 같은 대규모 성능 최적화(대규모 최적화)이고, 다른 하나는 소규모 성능 최적화(소형 최적화)입니다. 작은 성능 최적화가 때로는 매우 유용할 수 있습니다. 코드를 약간 변경하고 한 번에 수천 번 또는 만 번 호출합니다. 성능을 크게 최적화하면 애플리케이션 속도가 크게 향상되는 것을 확인할 수 있습니다. 작은 성능 최적화로는 요청당 1마이크로초만 향상될 수 있지만, 일일 요청 수가 많으면 애플리케이션의 성능이 크게 향상됩니다.
데이터 계층 성능
애플리케이션의 성능을 최적화하려는 경우 다음 순서로 작업할 수 있습니다. 코드가 데이터베이스에 액세스해야 합니까? 그렇다면 데이터베이스에 얼마나 자주 액세스해야 합니까? 마찬가지로 이 테스트 방법은 웹 서비스나 원격 기능을 사용하는 프로그램 코드에서도 사용할 수 있습니다. 이 기사에서는 웹 서비스와 Remoting을 사용한 프로그램 최적화 문제에 대해서는 다루지 않습니다.
코드에 데이터베이스에 액세스해야 하는 요청이 있고 다른 곳에서 동일한 기능을 구현하는 코드가 있는 경우 먼저 이를 최적화해야 합니다. 수정하고 개선하고 계속 테스트하세요. 매우 큰 성능 문제가 없는 한 쿼리 최적화, 데이터베이스 연결, 데이터 세트 크기 반환 및 쿼리 반환에 걸리는 시간을 사용하는 것이 좋습니다.
경험 요약을 바탕으로 애플리케이션의 성능을 향상시키는 데 도움이 될 수 있는 10가지 경험을 살펴보고 효율성이 얼마나 향상되는지 가장 큰 것부터 작은 것까지 순서대로 설명하겠습니다.
1. 여러 데이터 세트 반환
데이터베이스 액세스 코드를 확인하여 여러 번 반환되는 요청이 있는지 확인하세요. 왕복할 때마다 애플리케이션이 응답할 수 있는 초당 요청 수가 줄어듭니다. 단일 데이터베이스 요청으로 여러 결과 세트를 반환함으로써 데이터베이스와 통신하는 데 걸리는 시간을 줄이고, 시스템을 확장 가능하게 하며, 요청에 응답하기 위한 데이터베이스 서버의 워크로드를 줄입니다.
동적 SQL 문을 사용하여 여러 데이터 세트를 반환하는 경우 동적 SQL 문 대신 저장 프로시저를 사용하는 것이 좋습니다. 저장 프로시저에 비즈니스 논리를 작성할지 여부는 다소 논란의 여지가 있습니다. 하지만 저장 프로시저에 비즈니스 논리를 작성하면 반환되는 결과 집합의 크기를 제한하고 네트워크 데이터 트래픽을 줄이며 논리 계층에서 데이터를 필터링할 필요가 없어진다는 점은 좋은 일입니다.
SqlCommand 개체의 ExecuteReader 메서드를 사용하여 강력한 형식의 비즈니스 개체를 반환한 다음 NextResult 메서드를 호출하여 데이터 집합 포인터를 이동하여 데이터 집합을 찾습니다. 예제 1에서는 여러 ArrayList 강력한 형식의 개체를 반환하는 예를 보여줍니다. 데이터베이스에서 필요한 데이터만 반환하면 서버의 메모리 소비를 크게 줄일 수 있습니다.
2. 데이터 페이징
ASP. NET의 DataGrid에는 페이징이라는 매우 유용한 기능이 있습니다. DataGrid가 페이징을 허용하는 경우 특정 시간에 특정 페이지의 데이터만 다운로드합니다. 또한 데이터 페이징을 위한 탐색 모음이 있어 특정 페이지를 탐색하고 한 페이지만 다운로드할 수 있습니다. 한 번에 데이터.
그러나 여기에는 작은 단점이 있습니다. 즉, 모든 데이터를 DataGrid에 바인딩해야 한다는 것입니다. 즉, 데이터 레이어는 모든 데이터를 반환해야 하며, DataGrid는 현재 페이지에 필요한 데이터를 필터링하여 표시합니다. DataGrid를 사용하여 페이지를 매겨야 하는 10,000개의 레코드로 구성된 결과 집합이 있는 경우 DataGrid가 페이지당 25개의 데이터만 표시한다고 가정하면 각 요청에서 9975개의 데이터가 삭제된다는 의미입니다. 각 요청은 애플리케이션 성능에 큰 영향을 미치는 대규모 데이터 세트를 반환해야 합니다.
좋은 해결책은 페이징 저장 프로시저를 작성하는 것입니다. 예제 2는 Northwind 데이터베이스의 주문 테이블에 대한 페이징 저장 프로시저입니다. 현재 페이지 번호와 각 페이지에 표시된 항목 수만 전달하면 저장 프로시저가 해당 결과를 반환합니다.
서버 측에서는 데이터 페이징을 처리하기 위해 특별히 페이징 컨트롤을 작성했습니다. 여기서는 첫 번째 방법을 사용하여 저장 프로시저에 총 데이터 레코드 수와 필요한 결과 세트라는 두 개의 결과 세트를 반환했습니다.
반환되는 총 레코드 수는 실행 중인 쿼리에 따라 다릅니다. 예를 들어 where 조건은 반환되는 결과 집합의 크기를 제한할 수 있습니다. 페이징 인터페이스에서는 데이터 세트 레코드의 크기를 기준으로 전체 페이지 수를 계산해야 하므로 결과 세트의 레코드 수를 반환해야 합니다. 예를 들어 총 1,000,000개의 레코드가 있는 경우 where 조건을 사용하면 1,000개의 레코드만 반환하도록 필터링할 수 있습니다. 저장 프로시저의 페이징 논리는 표시해야 하는 데이터를 반환해야 합니다.
3. 연결 풀
TCP를 사용하여 애플리케이션을 데이터베이스에 연결하는 것은 비용이 많이 들고 시간도 많이 걸립니다. Microsoft 개발자는 연결 풀을 사용하여 데이터베이스 연결을 재사용할 수 있습니다. 연결 풀은 각 요청에 대해 데이터베이스에 연결하기 위해 TCP를 사용하는 대신 유효한 연결이 없을 때만 새 TCP 연결을 생성합니다. 연결이 닫히면 풀에 배치되고 데이터베이스에 대한 연결을 계속 유지하므로 데이터베이스에 대한 TCP 연결 수가 줄어듭니다.
물론, 닫는 것을 잊은 연결에 주의를 기울여야 합니다. 사용 후 즉시 연결을 닫아야 합니다. 제가 강조하고 싶은 것은 누가 뭐라고 하든 .net 프레임워크의 GC(가비지 수집기)는 항상 연결 개체의 사용을 마친 후 연결 개체의 Close 또는 Dispose 메서드를 호출하여 명시적으로 연결을 닫는다는 것입니다. CLR이 예상한 시간 내에 연결을 닫을 것이라고 기대하지 마십시오. 비록 CLR이 결국 개체를 삭제하고 연결을 닫을지라도 이러한 작업을 언제 수행할지는 확실하지 않습니다.
연결 풀 최적화를 사용하려면 먼저 연결을 열고 데이터를 처리한 다음 연결을 닫는 두 가지 규칙이 있습니다. 요청당 연결을 여러 번 열거나 닫아야 하는 경우 항상 측면 연결을 열고 이를 각 메서드에 전달하는 것보다 낫습니다. 둘째, 동일한 연결 문자열(또는 통합 인증을 사용하는 경우 동일한 사용자 ID)을 사용합니다. 동일한 연결 문자열을 사용하지 않는 경우(예: 로그인한 사용자를 기반으로 하는 연결 문자열을 사용하는 경우) 연결 풀의 최적화 기능을 활용할 수 없습니다. 통합 인수를 사용하는 경우에는 사용자가 많아 Connection Pool의 최적화 기능을 최대한 활용할 수 없습니다. .NET CLR은 연결 풀 추적을 포함하여 프로그램 성능 특성을 추적해야 할 때 매우 유용한 데이터 성능 카운터를 제공합니다.
애플리케이션이 데이터베이스와 같은 다른 시스템의 리소스에 연결할 때마다 리소스에 연결하는 데 걸리는 시간, 데이터를 수신하고 보내는 데 걸리는 시간, 되돌아가는 횟수를 최적화하는 데 집중해야 합니다. . 애플리케이션의 모든 프로세스 홉을 최적화하는 것은 애플리케이션 성능 향상을 위한 출발점입니다.
애플리케이션 계층에는 데이터 계층에 연결하고, 해당 클래스의 인스턴스로 데이터를 전송하고, 비즈니스를 처리하는 논리가 포함되어 있습니다. 예를 들어 커뮤니티 서버에서는 포럼 또는 스레드 컬렉션을 조합한 다음 인증과 같은 비즈니스 논리를 적용해야 합니다. 더 중요한 것은 여기에서 캐싱 논리를 완료해야 한다는 것입니다.
4. ASP. NET 캐시 API
응용 프로그램을 작성하기 전에 가장 먼저 해야 할 일은 응용 프로그램이 ASP.NET의 캐싱 기능을 최대한 활용하도록 만드는 것입니다.
구성 요소를 Asp.net 응용 프로그램에서 실행하려면 프로젝트에서 System.Web.dll을 참조하기만 하면 됩니다. 그런 다음 HttpRuntime.Cache 속성을 사용하여 캐시에 액세스합니다(Page.Cache 또는 HttpContext.Cache를 통해서도 액세스할 수 있음).
데이터 캐싱에는 몇 가지 규칙이 있습니다. 첫째, 데이터가 자주 사용될 수 있으며 이 데이터를 캐시할 수 있습니다. 둘째, 데이터의 액세스 빈도가 매우 높거나 데이터 조각의 액세스 빈도는 높지 않지만 해당 데이터의 수명주기가 매우 길다는 점입니다. 세 번째는 종종 무시되는 문제입니다. 때로는 너무 많은 데이터를 캐시합니다. 일반적으로 X86 시스템에서는 캐시하려는 데이터가 800M을 초과하면 메모리 오버플로 오류가 발생합니다. 따라서 캐시가 제한됩니다. 즉, 캐시 세트의 크기를 추정하고 캐시 세트의 크기를 10 미만으로 제한해야 합니다. 그렇지 않으면 문제가 발생할 수 있습니다. Asp.net에서 캐시가 너무 크면 특히 큰 DataSet 개체가 캐시되는 경우 메모리 오버플로 오류가 보고됩니다.
다음은 이해해야 할 몇 가지 중요한 캐싱 메커니즘입니다. 첫째, 캐시는 "가장 최근에 사용된" 원칙(최근에 가장 적게 사용된 알고리즘)을 구현합니다. 캐시가 거의 없으면 쓸모 없는 캐시를 자동으로 강제로 지웁니다. 둘째, "조건부 종속성" 강제 제거(만료 종속성) 원칙에 따라 조건은 시간, 키워드 및 파일이 될 수 있습니다. 조건으로 시간이 가장 일반적으로 사용됩니다. 데이터베이스 조건인 asp.net2.0에는 더욱 강력한 조건이 추가되었습니다. 데이터베이스의 데이터가 변경되면 캐시가 강제로 지워집니다. 데이터베이스 조건부 종속성에 대한 자세한 내용은 MSDN Magazine 2004년 7월호에 실린 Dino Esposito의 최첨단 칼럼을 참조하십시오. Asp.net의 캐시 아키텍처는 아래 그림에 나와 있습니다.
5. 사전 요청 캐싱
앞서 일부 부분에서는 약간의 성능 향상만 있어도 큰 성능 향상을 얻을 수 있다고 언급한 바 있습니다. 저는 사전 요청 캐싱을 사용하여 프로그램 성능을 향상시키는 것을 정말 좋아합니다.
Cache API는 일정 기간 동안 데이터를 저장하도록 설계되어 있지만 사전 요청 캐시는 특정 요청의 내용만 일정 기간 동안 저장합니다. 특정 요청의 액세스 빈도가 높고 이 요청은 데이터를 한 번만 추출, 적용, 수정 또는 업데이트하면 됩니다. 그런 다음 요청을 사전 캐시할 수 있습니다. 설명하기 위해 예를 들어 보겠습니다.
CS 포럼 애플리케이션에서 각 페이지의 서버 제어에는 스킨을 결정하고 사용할 스타일 시트와 기타 개인화된 사항을 결정하기 위한 사용자 정의 데이터가 필요합니다. 여기에 있는 데이터 중 일부는 장기간 저장해야 할 수도 있지만 그렇지 않은 경우도 있습니다. 예를 들어 컨트롤의 스킨 데이터는 한 번만 적용하면 항상 사용할 수 있습니다.
사전 요청 캐싱을 구현하려면 Asp.net의 HttpContext 클래스를 사용하십시오. HttpContext 클래스의 인스턴스는 모든 요청에 대해 생성되며 요청 중 어디에서나 HttpContext.Current 속성을 통해 액세스할 수 있습니다. HttpContext 클래스에는 Items 컬렉션 속성이 있으며, 모든 개체와 데이터는 이 컬렉션에 추가되고 요청 중에 캐시됩니다. 캐시를 사용하여 자주 액세스하는 데이터를 캐시하는 것처럼 HttpContext.Items를 사용하여 각 요청에 사용되는 기본 데이터를 캐시할 수 있습니다. 그 뒤에 있는 논리는 간단합니다. HttpContext.Items에 데이터를 추가한 다음 그 데이터를 읽습니다.
6. 백그라운드 처리
위의 방법을 사용하면 애플리케이션이 매우 빠르게 실행됩니다. 그렇죠? 그러나 어떤 시점에서는 프로그램의 요청에서 매우 시간이 많이 걸리는 작업이 수행될 수 있습니다. 이메일을 보내거나 제출된 데이터의 정확성을 확인하는 등의 작업을 수행합니다.
asp.net 포럼 1.0을 CS에 통합했을 때 새 게시물을 제출하는 것이 매우 느리다는 사실을 발견했습니다. 새 게시물이 추가될 때마다 애플리케이션은 먼저 게시물이 중복되었는지 확인한 다음 "badword" 필터를 사용하여 필터링하고, 이미지 첨부 코드를 확인하고, 게시물을 색인화하고, 적절한 대기열에 추가하고, 유효성을 검사해야 합니다. 첨부 파일을 삭제하고 마지막으로 이메일을 구독자의 사서함으로 보냅니다. 분명히 이것은 많은 작업입니다.
결과적으로 이메일을 색인화하고 보내는 데 많은 시간이 소요됩니다. 게시물을 인덱싱하는 작업은 시간이 많이 걸리며, 구독자에게 이메일을 보내려면 SMTP 서비스에 연결한 후 각 구독자에게 이메일을 보내야 합니다.
모든 요청에 대해 이메일 인덱싱 및 전송을 트리거할 필요는 없습니다. 이상적으로는 이러한 작업을 일괄 처리하여 한 번에 25개의 이메일만 보내거나 5분마다 모든 새 이메일을 보내려고 합니다. 우리는 데이터베이스 프로토타입 캐시와 동일한 코드를 사용하기로 결정했지만 실패했기 때문에 VS.NET 2005로 돌아가야 했습니다.
System.Threading 네임스페이스 아래에 Timer 클래스가 있습니다. 이 클래스는 매우 유용하지만 이를 아는 사람은 거의 없으며 이를 아는 웹 개발자도 더 적습니다. 이 클래스의 인스턴스를 생성하면 Timer 클래스는 지정된 시간마다 스레드 풀의 스레드에서 지정된 콜백 함수를 호출합니다. 이는 요청이 없을 때에도 ASP.NET 응용 프로그램이 실행될 수 있음을 의미합니다. 이는 나중에 다룰 해결 방법입니다. 모든 요청에 대해 인덱싱 및 이메일 작업을 실행할 필요 없이 백그라운드에서 실행되도록 할 수 있습니다.
백그라운드 실행 기술에는 두 가지 문제가 있습니다. 첫 번째는 애플리케이션 도메인이 제거되면 Timer 클래스 인스턴스의 실행이 중지된다는 것입니다. 즉, 콜백 메서드가 호출되지 않습니다. 또한 CLR의 각 프로세스에는 많은 스레드가 실행되고 있기 때문에 Timer에서 실행할 스레드를 구하는 것이 어렵거나 실행할 수는 있지만 지연이 발생합니다. Asp.net 계층에서는 이 기술을 가능한 한 적게 사용하여 프로세스의 스레드 수를 줄이거나 요청이 스레드의 작은 부분만 사용하도록 허용해야 합니다. 물론 비동기 작업이 많은 경우에만 사용할 수 있습니다.
여기에 코드를 게시할 공간이 충분하지 않습니다. http://www.rob-howard.net/ 에서 샘플 프로그램을 다운로드할 수 있습니다. Blackbelt TechEd 2004 샘플 프로그램을 다운로드하세요.
7. 페이지 출력 캐싱 및 프록시 서비스
Asp.net은 인터페이스 계층입니다(또는 그래야 합니다). 여기에는 페이지, 사용자 컨트롤, 서버 컨트롤(HttpHandler 및 HttpModules) 및 이들이 생성하는 콘텐츠가 포함됩니다. html, xml, imgae 또는 기타 데이터를 출력하는 Asp.net 페이지가 있고 코드를 사용하여 각 요청에 대해 동일한 출력 콘텐츠를 생성하는 경우 페이지 출력 캐싱 사용을 고려해야 합니다.
다음 코드 줄을 페이지에 복사하면 됩니다.
<%@ PageOutputCache VaryByParams=”없음” 기간=”60” %>
첫 번째 요청에서 생성된 페이지를 효과적으로 사용하여 캐시된 콘텐츠를 출력하고 60초 후에 페이지 콘텐츠를 다시 생성할 수 있습니다. 이 기술은 실제로 일부 저수준 캐시 API를 사용하여 구현됩니다. 위에서 언급한 VaryByParams 매개변수와 같이 페이지 출력 캐싱을 위해 구성할 수 있는 여러 매개변수가 있습니다. 이 매개변수는 Http Get 또는 Http Post 요청 모드에서 출력을 캐시하도록 지정할 수도 있습니다. 예를 들어 이 매개변수를 VaryByParams="Report"로 설정하면 default.aspx?Report=1 또는 default.aspx?Report=2에서 요청한 출력이 캐시됩니다. 매개변수 값은 세미콜론으로 구분된 여러 매개변수일 수 있습니다.
많은 사람들은 페이지 출력 캐싱을 사용할 때 ASP.NET이 HTTP 헤더 세트(HTTP 헤더)를 생성하고 이를 다운스트림 캐시 서버에 저장한다는 사실을 인식하지 못합니다. 이 정보는 Microsoft 인터넷 보안과 속도를 높이는 데 사용될 수 있습니다. 서버의 응답 속도. HTTP 캐시 헤더가 재설정되면 요청된 콘텐츠가 네트워크 리소스에 캐시됩니다. 클라이언트가 콘텐츠를 다시 요청하면 더 이상 원본 서버에서 콘텐츠를 가져오지 않고 캐시에서 직접 콘텐츠를 가져옵니다.
페이지 출력 캐싱을 사용하면 애플리케이션 성능이 향상되지 않지만 캐시된 페이지 콘텐츠가 서버에서 로드되는 횟수는 줄어듭니다. 물론 이는 익명 사용자가 액세스할 수 있는 페이지를 캐싱하는 것으로 제한됩니다. 페이지가 캐시되면 더 이상 인증 작업을 수행할 수 없기 때문입니다.
8. IIS6.0의 커널 캐싱 사용
응용 프로그램이 IIS 6.0(Windows Server 2003)에서 실행되고 있지 않다면 응용 프로그램 성능을 향상시킬 수 있는 몇 가지 좋은 방법을 잃어버린 것입니다. 일곱 번째 방법에서는 페이지 출력 캐싱을 사용하여 애플리케이션 성능을 향상시키는 방법에 대해 이야기했습니다. IIS5.0에서는 IIS에 요청이 오면 IIS는 이를 asp.net으로 전송합니다. 페이지 출력 캐시가 적용되면 ASP.NET의 HttpHandler는 요청을 받고 HttpHandler는 캐시에서 콘텐츠를 전송합니다. . 꺼내서 돌려주세요.
IIS6.0을 사용하는 경우 커널 캐싱이라는 매우 좋은 기능이 있으므로 asp.net 프로그램에서 코드를 수정할 필요가 없습니다. asp.net이 캐시된 요청을 받으면 IIS의 커널 캐시는 캐시에서 해당 요청의 복사본을 가져옵니다. 요청이 네트워크에서 오면 커널 계층이 요청을 받습니다. 요청이 캐시되면 캐시된 데이터를 직접 반환하고 작업이 완료됩니다. 이는 IIS 커널 캐싱을 사용하여 페이지 출력을 캐시하면 놀라운 성능 향상을 얻을 수 있음을 의미합니다. VS.NET 2005용 asp.net을 개발할 때 저는 asp.net 성능을 담당하는 프로그램 관리자였습니다. 저는 모든 일일 보고서 데이터를 살펴보고 항상 커널 모델 캐싱을 사용한 결과를 찾았습니다. 가장 빠릅니다. 이들의 공통적인 특징은 네트워크 요청과 응답이 크지만 IIS는 CPU 리소스의 5%만 차지한다는 것입니다. 정말 놀랍습니다. IIS 6.0을 사용하는 데는 여러 가지 이유가 있지만 커널 캐싱이 가장 좋습니다.
9. Gzip으로 데이터 압축
CPU 사용량이 너무 높지 않은 한 서버 성능을 향상시키는 기술을 사용해야 합니다. gzip을 사용하여 데이터를 압축하면 서버로 보내는 데이터의 양을 줄이고, 페이지 실행 속도를 향상시키며, 네트워크 트래픽도 줄일 수 있습니다. 데이터를 더 잘 압축하는 방법은 보내려는 데이터와 클라이언트의 브라우저가 이를 지원하는지 여부에 따라 다릅니다(IIS는 gzip으로 압축된 데이터를 클라이언트에 보내고 클라이언트는 이를 구문 분석하기 위해 gzip을 지원해야 함, IE6.0 및 Firefox). 이러한 방식으로 서버는 초당 더 많은 요청에 응답할 수 있으며 마찬가지로 응답으로 전송되는 데이터의 양도 줄어들고 더 많은 요청을 보낼 수 있습니다.
좋은 소식은 gzip 압축이 IIS6.0에 통합되어 IIS5.0의 gzip보다 낫다는 것입니다. 불행하게도 IIS 6.0에서 gzip 압축을 활성화하려면 IIS 6.0의 속성 대화 상자에서 설정할 수 없습니다. IIS 개발 팀은 gzip 압축 기능을 개발했지만 관리자가 관리자 창에서 이를 쉽게 활성화할 수 있도록 하는 것을 잊어버렸습니다. gzip 압축을 활성화하려면 IIS6.0 xml 구성 파일에서만 해당 구성을 수정할 수 있습니다.
이 글 외에도 Brad Wilson이 쓴 <<IIS6 Compression>> 글( http://www.dotnetdevs.com/articles/IIS6compression.aspx )도 읽어봐야겠습니다. 기본 지식을 소개하는 글도 있습니다. aspx 압축의 IIS에서 ASPX 압축을 활성화합니다. 그러나 동적 압축과 커널 캐싱은 IIS6에서 상호 배타적입니다.
10. 서버 컨트롤의 ViewState
ViewState는 숨겨진 필드에 페이지를 생성하는 데 사용되는 상태 값을 저장하는 데 사용되는 asp.net의 기능입니다. 페이지가 서버에 다시 게시되면 서버는 ViewState의 데이터를 구문 분석, 확인 및 적용하여 페이지의 컨트롤 트리를 복원합니다. ViewState는 쿠키나 서버 메모리를 사용하지 않고 클라이언트 상태를 유지할 수 있는 매우 유용한 기능입니다. 대부분의 서버 컨트롤은 ViewState를 사용하여 페이지에서 사용자와 상호 작용하는 요소의 상태 값을 유지합니다. 예를 들어 페이징을 위해 현재 페이지의 페이지 번호를 저장합니다.
ViewState를 사용하면 몇 가지 부정적인 효과가 발생합니다. 첫째, 서버의 응답 및 요청 시간이 늘어납니다. 둘째, 포스트백할 때마다 데이터를 직렬화 및 역직렬화하는 데 시간이 추가됩니다. 마지막으로 서버에서 더 많은 메모리를 소비합니다.
많은 서버 컨트롤은 잘 알려진 DataGrid와 같은 ViewState를 사용하는 경향이 있으며 때로는 이를 사용할 필요가 없습니다. ViewState는 기본적으로 활성화되어 있습니다. ViewState를 사용하지 않으려면 컨트롤이나 페이지 수준에서 비활성화할 수 있습니다. 컨트롤에서는 EnableViewState 속성을 False로 설정하기만 하면 됩니다. 또한 페이지에서 설정하여 해당 범위를 전체 페이지로 확장할 수도 있습니다.
<%@ 페이지 EnableViewState=”false” %>
페이지에 포스트백이 필요하지 않거나 페이지가 요청될 때마다 컨트롤을 사용하여 렌더링되는 경우입니다. 페이지 수준에서 ViewState를 꺼야 합니다.
요약
고성능 ASP.NET 응용 프로그램 작성을 향상시키는 데 도움이 될 것으로 생각되는 몇 가지 팁을 제공합니다. 이 문서에 언급된 ASP.NET 성능 향상을 위한 팁은 단지 시작점일 뿐입니다. NET "성능" 책입니다. 자신의 연습을 통해서만 프로젝트에 가장 도움이 될 기술을 찾을 수 있습니다. 그러나 이러한 팁은 개발 여정에 대한 가이드 역할을 할 수 있습니다. 소프트웨어 개발에서는 프로젝트마다 다르기 때문에 이들 중 어느 것도 절대적으로 유용하지 않습니다.
