이 기사에서는 ASP.NET 웹 애플리케이션의 성능을 향상시키는 몇 가지 방법과 기법을 소개합니다. 우리 모두는 성능 문제를 해결하는 것이 지루한 작업이라는 것을 알고 있으며, 성능 문제가 발생하면 모두가 코드를 작성한 개발자를 비난합니다.
다음은 번역입니다
성능 문제를 어떻게 해결합니까? 다음은 응용 시스템 출시 전 .NET 개발자들이 확인해야 할 사항들이다.
1.debug="false"
ASP.NET 웹 애플리케이션 생성 시 기본 설정은 "true"입니다. 개발 중에는 "true"로 설정하는 것이 매우 유용하지만, 애플리케이션이 출시 및 배포되면 "false"로 설정해야 합니다.
<compilation defaultLanguage="C#" debug="false" targetFramework="4.0" />
2. 트레이싱 끄기
트레이싱이 참 무서운데, 끄는 걸 잊으신 적 있으신가요? 작동하지 않으면 web.config를 편집하고 닫으십시오. 프로그램 리소스를 많이 차지하게 됩니다.
<trace enabled="false" requestLimit=”10” pageoutput=”false” traceMode=”SortByTime” localOnly=”true”>
3. 세션 비활성화
세션 추적이 필요하지 않은 경우에는 반드시 비활성화해 주시기 바랍니다. 각 asp.net 페이지에서 다음을 설정할 수 있습니다.
<%@ page language="c#" codebehind="webform1.aspx.cs" autoeventwireup="false" inherits="webapplication1.webform1" enablesessionstate="false" %>
4. 릴리스 버전을 사용하여 애플리케이션을 배포합니다.
프로덕션 환경에 애플리케이션을 배포할 때 반드시 다음을 사용하세요. 디버그 모드 대신 릴리스 버전 모드. 디버깅 템플릿을 사용하는 경우 요청 시간 초과가 발생하는 것은 매우 쉽습니다. 릴리스 버전에 배포하면 속도가 크게 향상되는 것을 확인할 수 있습니다.
5. 페이지의 상태 보기를 닫습니다.
보기 상태는 주로 제출 후 에코에 사용됩니다. 페이지의 데이터가 이 페이지에 제출될 때만 유용합니다. 기본값은 "true"입니다. 양식 데이터 포스트백을 사용하지 않는 경우 상태 보기를 끌 수 있습니다.
<%@ Page EnableViewState="false" %>
6. Response.Redirect 사용을 피하세요
리디렉션은 현재 물리적 서버에서 개발 점프에만 사용됩니다. 이 서버 개발 과정에서 페이지만 리디렉션하는 경우 Server.Transfer 구문을 사용하면 불필요한 클라이언트 리디렉션을 많이 줄일 수 있습니다.
7. StringBuilder 클래스를 사용하고 ToString() 메서드를 사용합니다.
String 클래스 객체는 변경할 수 없습니다. String 객체를 재할당하는 것은 본질적으로 String 객체를 다시 생성하고 이를 새 값이 개체에 할당되고 해당 메서드 ToString이 성능을 크게 향상시키지 않습니다. 문자열 작업 시 .NET 네임스페이스가 System.Text인 StringBuilder 클래스를 사용하는 것이 가장 좋습니다. 이 클래스는 새로운 객체를 생성하지 않고 Append, Remove, Insert 등의 메소드를 통해 문자열에 직접 연산을 수행하고, ToString 메소드를 통해 연산 결과를 반환합니다. 정의 및 동작문은 다음과 같습니다
int num; System.Text.StringBuilder str = new System.Text.StringBuilder(); //创建字符串 str.Append(num.ToString()); //添加数值num Response.Write(str.ToString); //显示操作结果
8. 예외 발생을 피하세요
예외로 인해 속도가 느려지고 애플리케이션 페이지가 비정상적으로 표시되어 다른 작업을 수행할 수 없게 됩니다. . try / catch를 사용하여 로그 파일에 예외를 기록할 수 있습니다.
9. finally 방법을 사용하여 리소스를 재활용하세요
애플리케이션 개발 중에 다른 데이터베이스 연결을 많이 사용하고 파일에 액세스하는 경우 사용 후에는 반드시 닫아주세요. finally 블록은 프로그램에서 실행되는 마지막 블록이므로 그 안에 있는 코드는 반드시 이 개발 메서드 블록에서 실행되어야 합니다.
10. 클라이언트측 스크립트 확인을 사용하세요.
서버 개발측 확인 대신 클라이언트측 확인을 사용하세요. 서버 개발 측 데이터 유효성 검사는 많은 서버 개발 리소스를 소비하며 반환할 페이지 데이터도 대량으로 필요합니다.
11. Page.IsPostback 사용
포스트백 코드를 너무 많이 실행하지 않도록 주의하세요. Page.IsPostBack 속성을 사용하면 페이지가 처음 로드될 때 페이지 초기화 논리만 실행되고 응답이 클라이언트에 다시 게시되지 않도록 할 수 있습니다.
12. 페이징 사용
대부분의 웹 애플리케이션 데이터는 표 형식으로 표시됩니다. 페이지 매김은 애플리케이션 개발 효율성을 활용합니다. 한 번에 작은 부분의 데이터를 표시해 보십시오. 그러면 페이지 표시 속도가 빨라집니다.
13. Ajax를 사용하여 비동기 호출을 수행합니다.
Ajax 메서드를 사용하여 비동기 호출을 수행합니다.
14. 사용하지 않는 HttpModules 삭제
httpModules의 경우 모든 웹 애플리케이션에 삽입할 수 있는 범용 HttpApplication 이벤트 후크를 설정하는 것으로 이해할 수 있습니다. HttpModule을 사용하면 재사용이 가능하며 애플리케이션별 코드가 필요하지 않고 web.config의 항목만 필요합니다. web.config 파일에서 사용되지 않는 HttpModule을 삭제합니다.
15. 재귀 함수/중첩 루프를 피하세요
성능 향상을 위해서는 모든 프로그래밍 언어에서 중첩 루프와 재귀 함수를 피해야 합니다.
16. 불필요한 서버 컨트롤을 사용하지 마세요
ASP.NET에서는 다수의 서버 측 컨트롤이 프로그램 개발을 용이하게 하지만 성능 저하를 초래할 수도 있습니다. 서버 측 컨트롤을 작동하여 서버와의 왕복 프로세스를 생성합니다. 따라서 Server Control은 필요 이상으로 적게 사용해야 합니다.
17. 여러 작업을 호출할 때는 멀티스레딩을 사용하세요
문제가 발생하면 이 문제로 인해 단일 스레드가 오랫동안 실행되지 않습니다. 따라서 여러 스레드를 사용하여 애플리케이션의 응답성을 높일 수 있습니다.
18. 데이터베이스 연결 및 종료
데이터베이스 리소스에 액세스하려면 연결 생성, 연결 열기, 연결 닫기 등 여러 작업이 필요합니다. 이러한 프로세스에서는 인증을 통과하기 위해 데이터베이스와 정보를 여러 번 교환해야 하며, 이는 서버 리소스를 소비합니다. ASP.NET은 데이터베이스 열기 및 닫기의 성능 영향을 향상시키기 위해 연결 풀(Connection Pool)을 제공합니다. 시스템은 사용자의 데이터베이스 연결을 연결 풀에 넣었다가 필요할 때 꺼내고, 닫히면 연결을 회수하여 다음 연결 요청을 기다립니다. 연결 풀의 크기는 제한되어 있습니다. 연결 풀이 최대 제한에 도달한 후에도 여전히 연결을 생성해야 하는 경우 성능에 큰 영향을 미칩니다. 따라서 데이터베이스 연결을 설정한 후 실제로 작업이 필요한 경우에만 연결을 열고 사용 후 즉시 닫아 데이터베이스 연결이 열려 있는 시간을 최소화하고 연결 제한을 초과하지 않도록 하십시오.
19. 빨리 감기 전용 데이터 커서에 SqlDataReader 클래스 사용
SqlDataReader 클래스는 SQL Server 데이터베이스에서 검색된 피드 전용 데이터 스트림을 읽는 방법을 제공합니다. SqlDataReader 클래스는 ASP.NET 응용 프로그램을 만들 때 사용할 수 있는 상황이 발생하는 경우 DataSet 클래스보다 더 높은 성능을 제공합니다. 이는 SqlDataReader가 SQL Server의 기본 네트워크 데이터 전송 형식을 사용하여 데이터베이스 연결에서 직접 데이터를 읽기 때문입니다. 또한 SqlDataReader 클래스는 IEnumerable 인터페이스를 구현합니다. 이를 통해 데이터를 서버 컨트롤에 바인딩할 수도 있습니다. 자세한 내용은 SqlDataReader 클래스를 참조하세요. ASP.NET이 데이터에 액세스하는 방법에 대한 자세한 내용은 ASP.NET을 사용하여 데이터 액세스를 참조하세요.
20. 고성능 SQL 문 규칙
전체 테이블 스캔을 피하세요
where 절의 필드에 대한 null 값 판단을 피하세요
where 절에 != 또는 연산자를 사용하지 마세요.
조건을 연결하기 위해 or in where 절을 사용하지 마세요.
in과 not in도 주의해서 사용해야 합니다.
where 절의 "=" 왼쪽에서 함수, 산술 연산 또는 기타 표현식 연산을 수행하지 마세요
업데이트 문, 1~2개의 필드만 변경하는 경우 모든 필드를 업데이트하지 마세요.
많은 양의 데이터(여기서 수백 개의 레코드는 큰 것으로 간주됨)가 있는 여러 테이블의 JOIN의 경우 먼저 페이지를 매긴 다음 조인해야 합니다. 그렇지 않으면 논리적 읽기가 매우 높아 성능이 저하됩니다. 열악함
가능한 한 varchar/를 사용하십시오. nvarchar는 char/nchar를 대체합니다.
21. 캐싱
캐싱은 일반인의 용어로 공간을 교환하는 기술입니다. 여기에서 짧은 시간 동안 서버는 데이터베이스나 실제 데이터 소스를 읽지 않고 메모리에 저장한 데이터를 읽습니다. 캐싱은 웹사이트 성능 최적화를 위해 필수적인 데이터 처리 메커니즘으로, 데이터베이스 부담을 효과적으로 완화할 수 있습니다. ASP.NET의 캐시는 크게
페이지 캐시
데이터 원본 캐시
사용자 지정 데이터 캐시
22. 로드 밸런싱 및 서버 수행 보너스
로드 밸런싱을 확장성을 달성하기 위한 수단으로만 보아서는 안 됩니다. 확장성은 확실히 향상되지만 요청과 사용자가 여러 서버에 분산되어 있기 때문에 웹 애플리케이션의 성능이 여러 번 향상됩니다.
23. FxCop을 통한 코드 검사 및 최적화
FxCop은 규칙 기반 엔진을 사용하여 코드의 비표준 부분을 확인하는 코드 분석 도구입니다. 이 엔진에 자신만의 규칙을 추가하세요. 몇 가지 규칙은 다음과 같습니다.
너무 많은 지역 변수 피하기
호출되지 않은 비공개 코드 피하기
인스턴스화되지 않은 내부 클래스 피하기
봉인되지 않은 속성 사용 피하기
불필요한 캐스트를 피하세요
참조 유형의 정적 필드를 인라인으로 초기화하세요
NeutralResourcesLanguageAttribute로 어셈블리를 표시하세요
멤버를 Static으로 표시하세요.
24.ASP.NET 성능 모니터링 도구
코드 성능을 모니터링하는 데 사용되는 도구입니다.
.NET 메모리 분석기
Red Gate ANTS 성능 분석 도구
Fiddler
성능 카운터
결론: 위 내용은 일부 성능입니다. 조정을 위한 팁. 성능 튜닝은 하루 이틀 작업이 아니라 반복적인 프로세스입니다. 웹 사이트 개발자의 경우 ASP.NET 응용 프로그램을 작성할 때 성능 문제에 주의를 기울이고, 좋은 습관을 기르고, 응용 프로그램 성능을 향상시키면 최소한 필요한 하드웨어 업그레이드를 연기하고 웹 사이트 비용을 줄일 수 있습니다.