ASP.NET 程序優化

1、SqlDataRead和Dataset的選擇

Sqldataread優勢：讀取數據很是快。若是對返回的數據不需作大量處理的狀況下，建議使用SqlDataReader，其性能要比datset好不少。缺點：直到數據讀完纔可close掉於數據庫的鏈接

(SqlDataReader 讀數據是快速向前的。SqlDataReader 類提供了一種讀取從 SQL Server 數據庫檢索的只進數據流的方法。它使用 SQL Server 的本機網絡數據傳輸格式從數據庫鏈接直接讀取數據。DataReader需及時顯式的close。可及時的釋放對數據的鏈接。)

Dataset是把數據讀出，緩存在內存中。缺點：對內存的佔用較高。若是對返回的數據需作大量的處理用Dataset比較好些能夠減小對數據庫的鏈接操做。優勢：只需鏈接一次就可close於數據庫的鏈接

*通常狀況下,讀取大量數據,對返回數據不作大量處理用SqlDataReader.對返回數據大量處理用datset比較合適.對SqlDataReader和Dataset的選擇取決於程序功能的實現。

2、ExecuteNonQuery和ExecuteScalar

對數據的更新不須要返回結果集，建議使用ExecuteNonQuery。因爲不返回結果集可省掉網絡數據傳輸。它僅僅返回受影響的行數。若是隻需更新數據用ExecuteNonQuery性能的開銷比較小。

ExecuteScalar它只返回結果集中第一行的第一列。使用 ExecuteScalar 方法從數據庫中檢索單個值(例如id號)。與使用 ExecuteReader 方法， 返回的數據執行生成單個值所需的操做相比，此操做須要的代碼較少。

*只需更新數據用ExecuteNonQuery.單個值的查詢使用ExecuteScalar數據綁定的選擇

3、數據的綁定DataBinder

通常的綁定方法用DataBinder.eval 綁定沒必要關心數據來源(Dataread或dataset)。沒必要關心數據的類型eval會把這個數據對象轉換爲一個字符串。在底層綁定作了不少工做，使用了反射性能。正由於使用方便了，但卻影響了數據性能。來看下。當於dataset綁定時，DataItem其實式一個DataRowView(若是綁定的是一個數據讀取器(dataread)它就是一個IdataRecord。)所以直接轉換成DataRowView的話，將會給性能帶來很大提高。

*對數據的綁定建議使用。數據量大的時候可提升幾百倍的速度。使用時注意2方面：1.需在頁面添加.2.注意字段名的大小寫(要特別注意)。若是和查詢的不一致，在某些狀況下會致使比還要慢。若是想進一步提升速度，可採用的方法。不過其可讀性不高。

以上的是vb.net的寫法。在c#中：<@% ((DataRowView)Container.DataItem)["字段名"] %>

對查看頁面每一個執行過程狀態最簡單的辦法：其頁面的trace屬性爲true就可查看細節。

1、使用存儲過程：

一、性能方面：存儲過程提供了許多標準sql語言中所沒有的高級特性。其傳遞參數和執行邏輯表達式的功能，有助於應用程序設計者處理複雜任務。另外，存儲過程存儲在本地服務器上，減小了執行該過程所需的網絡傳輸寬帶和執行時間。(存儲過程已經對sql語句進行了預編譯，因此其執行速度比在程序裏執行sql語句快不少)

二、程序結構方面：從程序的可擴展性看，使用存儲過程會對程序之後的修改帶來方便。好比數據庫的結構改變了，只需修改相對應的存儲結構，和程序中的調用部分便可。這部分不屬於本文探討範圍，屬於程序結構設計方面。因此不在此展開。

三、程序安全性：使用存儲過程可避免SQL Injection攻擊。

2、查詢語句的優化(針對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)

主要針對幾個頁面屬性

一、EnableViewState(頁面的視圖狀態)。若是無特殊要求設置爲false。使用ViewState ，每一個對象都必須先序列化到 ViewState 中，而後再經過回傳進行反序列化，所以使用 ViewState是沒有代價的。儘可能減小使用對象，若是可能，儘可能減小放入 ViewState 中的對象的數目。下面狀況基本上能夠禁用viewstate：

(1)頁面控件 (.ascx)

(2)頁面不回傳給自身。

(3)無需對控件的事件處理。

(4)控件沒有動態的或數據綁定的屬性值(或對於每一個postpack都在代碼中處理)

單個頁面或每一個頁面都禁用 ViewState，以下所示：單個頁面： 每一個頁面：在 web.config 中 EnableSessionState保持默認值便可(若是頁面用到sessionstate它纔會佔用資源)。EnableViewStateMac若是無安全上的特殊要求，保持默認值。

二、Pagelayout.頁面佈局模型。建議使用Flowlayout(元素不帶絕對定位屬性添加).Gridlayout(絕對定位屬性)因爲採用絕對定位，將會比Flowlayout生產更多的代碼，主要是控件的定位信息。

三、項目發佈的時候切記解除頁面的Debug狀態。

四、Html語言的優化。個人建議是熟練掌握Html/javascript，少用vs.net2003自動生產的代碼，它會自動生成一些無用的html代碼。

五、smart navigation設置爲true能讓用戶明顯的感受性能提升。啓用此屬性後對客戶端和服務端影響不大.它能智能涮新須要涮新需涮新的部分.

4、控件的選擇：

Html控件和服務器控件的選擇。服務器控件帶來的方便和功能上的實現是html控件所不能比擬的。可是是以犧牲服務器端的資源來取得的。我我的建議：若是html控件達不到所要實現的功能，並且和一些腳本語言(如javascrpt/vbscript)結合也不能實現的話。纔會選擇服務器控件。選擇服務器控件後，也儘可能對其控件優化，如取消一些頁面狀態等(具體看控件的優化)

服務器控件的選擇：主要針對幾個經常使用數據控件說明一下：

DataGrid：自帶最強大的數據顯示控件，內置了對數據的修改、刪除、添加、分頁等不少實用功能。若是你只需對數據顯示的話，儘可能不要選擇DataGrid(它把數據都存儲在viewstate中).也不要使用自帶的分頁功能，microsoft在自動分頁的底層作了不少工做，雖然使用方便了，但性能開銷大了。

DataList：比DataGrid功能少了不少。但自定義性強了不少。特有的多行數據顯示，給咱們帶來了不少方便。DataGrid能實現的功能，它基本能實現。因此建議使用它。

Repeater：功能最少，但自定義性很是強。若是隻需對數據顯示，建議使用。因爲減小了不少功能，對服務器的性能帶來消耗最小。所以，若是是對數據顯示的話，我基本上都是選擇Repeater而後DataList最後DataGrid

*儘可能選擇html控件。能在客戶端實現的功能就在客戶端實現(熟練掌握javascript)，減小服務器的壓力。數據控件選擇順序：Repeater、DataList、DataGrid

5、服務器控件的優化：

一、Viewstate

控件的viewstate與頁面的viewstate基本是一致的。用來保存控件的一些狀態。處理原則和處理頁面的viewstate同樣。有興趣的能夠用Datagrid綁定數據測試下viewstate保存的數據量有多大，它所保存的數據基本和Datagrid顯示的數據量大小是等同的。

二、Ispostpack

默認false.須要產生事件的時候才需設置爲true.

控件的優化，主要看你對此控件的熟悉狀況。對控件內部運做的原理越瞭解，就會對其做出合適的優化。

性能優化是三兩句話說不清的，我所寫出的僅僅是冰山一角，性能的優化是靠平時經驗的積累和對程序的運做原理的不斷認知。

出處：http://blog.csdn.net/jacky4955/article/details/4458254