1. SqlDataRead 및 Dataset 선택 Sqldataread의 장점: 데이터 읽기 속도가 매우 빠릅니다. 반환된 데이터에 많은 처리가 필요하지 않은 경우 datset보다 성능이 훨씬 뛰어난 SqlDataReader를 사용하는 것이 좋습니다. 단점: 데이터를 읽을 때까지 데이터베이스에 대한 연결을 닫을 수 없습니다
(SqlDataReader는 빨리 감기 방향으로 데이터를 읽습니다. SqlDataReader 클래스는 SQL Server 데이터베이스에서 검색된 정방향 전용 데이터 스트림을 읽는 방법을 제공합니다. 이는 SQL Server의 기본 네트워크 데이터 전송 형식은 데이터베이스 연결에서 직접 데이터를 읽습니다. 데이터 연결을 적시에 해제하려면 DataReader를 명시적으로 닫아야 합니다.)
데이터 세트는 데이터를 읽고 메모리에 캐시합니다. 단점: 메모리 사용량이 높다. 반환된 데이터에 대해 많은 처리를 수행해야 하는 경우 Dataset을 사용하여 데이터베이스에 대한 연결 작업을 줄이는 것이 좋습니다. 장점: 데이터베이스에 대한 연결을 닫으려면 한 번만 연결하면 됩니다
. 일반적으로 많은 양의 데이터를 읽고 반환된 데이터에 대해 많은 처리를 수행하지 않으려면 SqlDataReader를 사용하십시오. 반환된 데이터를 처리하려면 datset을 사용하는 것이 더 적합합니다. SqlDataReader 및 Dataset의 선택은 프로그램 기능의 구현에 따라 달라집니다.
2. ExecuteNonQuery 및 ExecuteScalar는
데이터 업데이트 시 결과 집합을 반환할 필요가 없습니다. ExecuteNonQuery를 사용하는 것이 좋습니다. 결과 세트가 반환되지 않으므로 네트워크 데이터 전송은 생략될 수 있습니다. 단순히 영향을 받은 행 수를 반환합니다. 데이터 업데이트만 필요한 경우 ExecuteNonQuery의 성능 오버헤드는 상대적으로 적습니다.
ExecuteScalar는 결과 집합의 첫 번째 행의 첫 번째 열만 반환합니다. ExecuteScalar 메서드를 사용하여 데이터베이스에서 단일 값(예: ID 번호)을 검색합니다. 이 작업에는 반환된 데이터에 대해 단일 값을 생성하는 데 필요한 작업을 수행하기 위해 ExecuteReader 메서드를 사용하는 것보다 더 적은 코드가 필요합니다.
*ExecuteNonQuery를 사용하여 데이터를 업데이트하면 됩니다. 단일 값의 쿼리는 ExecuteScalar 데이터 바인딩 옵션을 사용합니다
. 3. 데이터 바인딩 DataBinder
일반 바인딩 방법 <%# DataBinder.Eval(Container.DataItem, "field name") %> DataBinder.eval 바인딩을 사용합니다. 데이터 소스(Dataread 또는 데이터 세트)에 관심이 없습니다. 데이터 유형에 대해 걱정할 필요가 없습니다. eval은 이 데이터 객체를 문자열로 변환합니다. 리플렉션 기능을 사용하여 기본 바인딩에 대한 많은 작업이 수행되었습니다. 사용하기 편리하다는 이유만으로 데이터 성능에 영향을 미치게 됩니다. <%# DataBinder.Eval(Container.DataItem, "field name") %>을 살펴보겠습니다. 데이터 세트에 바인딩되면 DataItem은 실제로 DataRowView입니다(데이터 판독기(dataread)에 바인딩된 경우 IdataRecord입니다.) 따라서 DataRowView로 직접 변환하면 성능이 크게 향상됩니다.
<%# ctype(Container.DataItem,DataRowView).Row("field name") %>
*데이터에는 <%# ctype(Container.DataItem,DataRowView).Row("field name") %> 사용을 권장합니다. 바인딩. 데이터의 양이 많으면 속도가 수백 배나 빨라질 수 있습니다. 사용할 때 두 가지 측면에 주의하세요. 1. 페이지에 <%@ Import 네임스페이스="System.Data"%>를 추가해야 합니다. 2. 필드 이름의 대소문자에 주의하세요. 쿼리와 일치하지 않는 경우 <%# DataBinder.Eval(Container.DataItem, "field name") %>보다 속도가 느려지는 경우도 있습니다. 속도를 더욱 향상시키려면 <%# ctype(Container.DataItem,DataRowView).Row(0) %> 메서드를 사용할 수 있습니다. 하지만 가독성은 높지 않습니다.
위는 vb.net의 작성방법입니다. C#에서: <@% ((DataRowView)Container.DataItem)["field name"] %>
페이지에서 각 실행 프로세스의 상태를 보는 가장 간단한 방법: 페이지의 추적 속성이 다음과 같은 경우 세부 정보를 볼 수 있습니다. 진실.
1. 저장 프로시저 사용:
1. 성능: 저장 프로시저는 표준 SQL 언어에는 없는 많은 고급 기능을 제공합니다. 매개변수를 전달하고 논리식을 실행하는 기능은 애플리케이션 설계자가 복잡한 작업을 처리하는 데 도움이 됩니다. 또한 저장 프로시저가 로컬 서버에 저장되므로 프로시저 실행에 필요한 네트워크 전송 대역폭과 실행 시간이 줄어듭니다. (저장 프로시저에는 sql 문이 미리 컴파일되어 있으므로 프로그램에서 sql 문을 실행하는 것보다 실행 속도가 훨씬 빠릅니다.)
2. 프로그램 구조: 프로그램 확장성 측면에서 저장 프로시저를 사용하면 향후 프로그램 수정에 영향을 미칩니다. 편의를 위해. 예를 들어, 데이터베이스 구조가 변경되면 해당 저장 구조와 프로그램 호출 부분만 수정하면 됩니다. 이 부분은 이 글의 범위에 속하지 않으며 프로그램 구조 설계에 속합니다. 그래서 여기서는 더 이상 설명하지 않겠습니다.
3. 프로그램 보안: 저장 프로시저를 사용하면 SQL 주입 공격을 피할 수 있습니다.
2. 쿼리문 최적화 (for sql server2000)
많은 사람들이 SQL문의 실행 효율성을 고려하지 않고 목적에 맞게만 SQL문을 작성합니다. 여기서는 테이블 순서를 최적화하는 방법만 제공합니다. (SQL 문의 최적화 및 원리는 SQL Server2000 연구 노트에서 논의됩니다.)
SQL 문의 실행 효율성을 위해 SQL Server2000의 쿼리 분석기를 사용할 수 있습니다. 명령문의 실행 프로세스를 봅니다.
테이블 순서 최적화: 일반적인 상황에서 sqlserver는 자동으로 테이블 연결을 최적화합니다. 예: select name,no from A Join B on A. id=B.id Join C on C.id=A.id where name='wang'A
테이블이 From에 먼저 나열되고 그 다음 B, 마지막으로 나열됩니다. C입니다. 그러나 SQL Server는 c 테이블을 먼저 사용할 수 있습니다. 선택 원칙은 쿼리를 단일 행 또는 몇 개의 행으로 제한하여 다른 테이블에서 검색되는 전체 데이터 양을 줄일 수 있다는 것입니다. 대부분의 경우 SQL Server가 최적의 선택을 하지만 복잡한 조인 쿼리가 예상보다 느린 경우 SET FORCEPLAN 문을 사용하여 SQL Server가 테이블이 나타나는 순서대로 테이블을 사용하도록 할 수 있습니다. 위의 예와 같이 SET FORCEPLAN ON......SET FORCEPLAN OFF를 추가하면 테이블의 실행 순서가 작성한 순서대로 실행됩니다. 테이블이 조인되는 순서를 선택하려면 쿼리 분석기에서 2가지 실행 효율성을 확인하세요.
*SET FORCEPLAN을 사용하여 테이블 연결 순서를 선택합니다
. 3. 페이지 최적화(.aspx)는
주로 여러 페이지 속성에 중점을 둡니다.
1. EnableViewState(페이지의 보기 상태). 특별한 요구 사항이 없으면 false로 설정합니다. ViewState를 사용하면 각 개체를 먼저 ViewState로 직렬화한 다음 포스트백을 통해 역직렬화해야 하므로 ViewState를 사용하는 데 비용이 들지 않습니다. 가능한 한 적은 수의 개체를 사용하고, 가능하다면 ViewState에 넣는 개체 수를 줄이세요. Viewstate는 기본적으로 다음과 같은 상황에서 비활성화될 수 있습니다.
(1) 페이지 제어(.ascx)
(2) 페이지는 자신에게 다시 전달되지 않습니다.
(3) 제어를 위한 이벤트 처리가 필요하지 않습니다.
(4) 컨트롤에 동적 또는 데이터 바인딩된 속성 값이 없습니다(또는 각 포스트팩에 대한 코드에서 처리됨).
다음과 같이 단일 페이지 또는 각 페이지에 대해 ViewState를 비활성화합니다. 단일 페이지: <%@ Page EnableViewState=" False" %> 각 페이지: web.config에서
2. 페이지 레이아웃 모델. Flowlayout(절대 위치 지정 속성 없이 요소가 추가됨)을 사용하는 것이 좋습니다. Gridlayout(절대 위치 지정 속성)은 절대 위치 지정, 주로 컨트롤의 위치 지정 정보를 사용하기 때문에 Flowlayout보다 더 많은 코드를 생성합니다.
3. 프로젝트를 릴리스할 때 페이지의 디버그 상태를 릴리스하는 것을 잊지 마세요.
4. HTML 언어 최적화. 내 제안은 Html/JavaScript에 능숙하고 vs.net2003에서 자동으로 생성된 코드를 적게 사용하는 것입니다. 그러면 쓸모없는 HTML 코드가 자동으로 생성됩니다.
5. 스마트 탐색을 true로 설정하면 사용자 성능이 크게 향상될 수 있습니다.
이속성
을 활성화하면 업데이트가 필요한 부분을 지능적으로 업데이트할 수 있으므로 클라이언트와 서버에 거의 영향을 미치지 않습니다.
HTML 컨트롤과 서버 컨트롤을 선택합니다. 서버 컨트롤이 제공하는 편리함과 기능적 구현은 HTML 컨트롤과 비교할 수 없습니다. 그러나 이는 서버 측 리소스를 희생하여 얻습니다. 내 개인적인 제안: HTML 컨트롤이 달성하려는 기능을 달성할 수 없고 일부 스크립팅 언어(예: javascrpt/vbscript)와 결합하면 달성할 수 없는 경우. 그래야만 서버 컨트롤이 선택됩니다. 서버 컨트롤을 선택한 후 일부 페이지 상태를 취소하는 등 해당 컨트롤을 최적화해 보십시오(구체적으로 컨트롤 최적화 참조).
서버 컨트롤 선택: 몇 가지 일반적인 데이터 컨트롤을 주로 설명합니다.
DataGrid: 가장 강력한 컨트롤과 함께 제공됩니다. 데이터 표시 컨트롤에는 데이터 수정, 삭제, 추가 및 페이징과 같은 많은 실용적인 기능이 내장되어 있습니다. 데이터만 표시해야 한다면 DataGrid를 선택하지 마십시오(모든 데이터를 viewstate에 저장함). 또한 내장된 페이징 기능을 사용하지 마십시오. 사용하기 편리하지만 성능 오버헤드가 엄청납니다.
DataList: DataGrid보다 기능이 훨씬 적습니다. 그러나 훨씬 더 사용자 정의가 가능합니다. 독특한 다중 라인 데이터 디스플레이는 우리에게 많은 편의성을 제공합니다. 기본적으로 DataGrid가 달성할 수 있는 기능을 구현할 수 있습니다. 따라서 사용하는 것이 좋습니다.
리피터: 기능은 가장 적지만 사용자 정의가 매우 쉽습니다. 데이터만 표시해야 하는 경우 사용하는 것이 좋습니다. 많은 기능의 축소로 인해 서버 성능 소모가 최소화됩니다. 따라서 데이터를 표시하려면 기본적으로 Repeater를 선택한 다음 DataList, 마지막으로 DataGrid
*를 선택하여 html 컨트롤을 선택하려고 합니다. 클라이언트에서 구현할 수 있는 기능을 클라이언트에서 구현(Javascript에 능숙)하여 서버에 대한 부담을 줄입니다. 데이터 컨트롤 선택 순서: Repeater, DataList, DataGrid
5. 서버 컨트롤 최적화:
1.
Viewstate 컨트롤의 viewstate는 기본적으로 페이지의 viewstate와 동일합니다. 컨트롤의 일부 상태를 저장하는 데 사용됩니다. 처리 원리는 페이지의 viewstate를 처리하는 것과 동일합니다. 관심이 있는 경우 Datagrid를 사용하여 데이터를 바인딩하여 viewstate에 의해 저장되는 데이터의 양을 테스트할 수 있습니다. 저장되는 데이터는 기본적으로 Datagrid에 표시되는 데이터의 양과 동일합니다.
2. Ispostpack
의기본값은 이벤트가 생성되어야 하는 경우 true로 설정되어야 합니다.
컨트롤의 최적화는 주로 이 컨트롤에 대한 익숙함에 달려 있습니다. 컨트롤의 내부 작동 방식을 더 잘 이해할수록 적절하게 최적화할 수 있습니다.
성능 최적화는 몇 문장으로 설명할 수 없습니다. 제가 쓴 내용은 빙산의 일각에 불과합니다. 성능 최적화는 일상적인 경험의 축적과 프로그램 작동 원리에 대한 지속적인 이해에 달려 있습니다.
6. 예외 문제
포럼에 사용자가 존재하지 않는 문제, 사용자 비밀번호가 잘못된 문제 등 일반적인 문제에는 예외를 사용할 필요가 없습니다. 예외를 인스턴스화하려면 많은 리소스가 필요하고 채워야 하기 때문입니다. 예외 정보(예외 유형, 예외가 발생한 예외 위치) 등), 물론 예외 사용을 피하는 것이 아니라 필요한 예외를 처리하기 위한 것입니다. 예외에 대한 원칙은 다음과 같습니다. 가능하면 사용하지 마세요. 시스템의 기존 예외를 사용할 수 있는 경우 자체 예외를 생성하지 마세요.