asp.net的性能優化原則和優化方向

現在java和.net仍然在争論誰更優秀，但是我沒有心思去和誰因為這些事情争得面紅耳赤，針對項目，有計劃的選擇才是正理。

最近做項目需要對系統進行性能優化，其實很多人都對性能有個希望，但是如何優化往往沒有頭緒，不知從何處下手，優化的原則是什麼？優化的原理是什麼？相信有些兄弟不是太清楚（當然我也不是很清楚），系統在開發周期内是沒有性能的優化時間的。沒有哪一個程式開發測試完成了，專門找一些時間做這些工作，我覺得啊，與其說叫性能優化不如叫性能積攢，也許是在班門弄斧，但是，今天把自己的一些感觸和一些值得注意的地方寫上來，與大家分享，歡迎大家補充。

總的來說，減少資源占用、減少記憶體占用、減少資料庫通路量，合理有效的組織代碼和SQL語句是性能優化的普遍原則。

減少資源占用、減少記憶體占用：

1、這兩個方面主要針對編碼過程，我們知道面向對象的程式設計思想講究的是最大程度的抽象現實（封裝、繼承和多态說的太多了，沒意思）。

就像我們購買一個整理箱，盡量要買合适的尺寸，既可以裝衣物，又可以裝玩具，老爸可以用，老媽也可以用，而不需要因為使用者的增多再去購買新的來實作。這就是現實生活中一種資源節省的典型例子，話題轉移到程式設計上，似乎有廠模式的影子。我們定義一個Instance，盡量減少New的出現頻率，比如說，不是條件限制的話，我們不應該在循環中定義比較重量級的執行個體，這樣将上一次建立的執行個體“抛棄”，有架構自行回收，再建個新的，如此往複，會造成性能下降的。

2、變量方面倒是沒有太多的講究，盡量不要聲明全局變量，本地變量最好也要和上面提到的做相同的處理。

3、方法上針對開發情況定義static，這樣可以有效的減少打對象的建立。

有的兄弟可能看出來了，我說的1和3有點沖突，變量和類（對象）如何做相同的處理。其實像String、int這樣的變量類型也都是對象，我們使用的時候同樣需要new出來的：String str = new String(“是樣的吧？”);

隻不過是這些類型我們用的太多了太頻繁了，.NET和java已經內建到架構中了。要說不同的話，對象級别的變量（執行個體）是運作的記憶體堆棧，String、int這樣的變量是運作線上程堆棧，程式運作結束，變量即消亡，不受架構的回收機制控制；對象級别的變量（執行個體）在記憶體中是有生存周期的，受架構的回收機制控制，這也是我們常說的Finalize的工作，檢測記憶體中在一定時間内不使用的或與其他對象無關聯的對象，然後回收，釋放記憶體。

唠叨了半天，還是先開正題吧！

一、SqlDataRead和Dataset的選擇

　　Sqldataread優點：讀取資料非常快。如果對傳回的資料不需做大量處理的情況下，建議使用SqlDataReader，其性能要比datset好很多。缺點：直到資料讀完才可close掉于資料庫的連接配接

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

　　Dataset是把資料讀出，緩存在記憶體中。缺點：對記憶體的占用較高。如果對傳回的資料需做大量的處理用Dataset比較好些可以減少對資料庫的連接配接操作。優點：隻需連接配接一次就可close于資料庫的連接配接

　　*一般情況下,讀取大量資料,對傳回資料不做大量處理用SqlDataReader.對傳回資料大量處理用datset比較合适.對SqlDataReader和Dataset的選擇取決于程式功能的實作。

二、ExecuteNonQuery和ExecuteScalar

　　對資料的更新不需要傳回結果集，建議使用ExecuteNonQuery。由于不傳回結果集可省掉網絡資料傳輸。它僅僅傳回受影響的行數。如果隻需更新資料用ExecuteNonQuery性能的開銷比較小。

　　ExecuteScalar它隻傳回結果集中第一行的第一列。使用 ExecuteScalar 方法從資料庫中檢索單個值（例如id号）。與使用 ExecuteReader 方法， 傳回的資料執行生成單個值所需的操作相比，此操作需要的代碼較少。

　　*隻需更新資料用ExecuteNonQuery.單個值的查詢使用ExecuteScalar資料綁定的選擇

三、資料的綁定DataBinder

　　一般的綁定方法<%# DataBinder.Eval(Container.DataItem, "字段名") %>用DataBinder.eval 綁定不必關心資料來源(Dataread或dataset)。不必關心資料的類型eval會把這個資料對象轉換為一個字元串。在底層綁定做了很多工作，使用了反射性能。正因為使用友善了，但卻影響了資料性能。來看下<%# DataBinder.Eval(Container.DataItem, "字段名") %>。當于dataset綁定時，DataItem其實式一個DataRowView（如果綁定的是一個資料讀取器（dataread）它就是一個IdataRecord。）是以直接轉換成DataRowView的話，将會給性能帶來很大提升。

　　<%# ctype(Container.DataItem,DataRowView).Row("字段名") %>

　　*對資料的綁定建議使用<%# ctype(Container.DataItem,DataRowView).Row("字段名") %>。資料量大的時候可提高幾百倍的速度。使用時注意2方面：1.需在頁面添加<%@ Import namespace="System.Data"%>.2.注意字段名的大小寫（要特别注意）。如果和查詢的不一緻，在某些情況下會導緻比<%# DataBinder.Eval(Container.DataItem, "字段名") %>還要慢。如果想進一步提高速度，可采用<%# ctype(Container.DataItem,DataRowView).Row(0) %>的方法。不過其可讀性不高。

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

　　對檢視頁面每個執行過程狀态最簡單的辦法：其頁面的trace屬性為true就可檢視細節。

四、使用存儲過程：

　　1、性能方面：存儲過程提供了許多标準sql語言中所沒有的進階特性。其傳遞參數和執行邏輯表達式的功能，有助于應用程式設計者處理複雜任務。另外，存儲過程存儲在本地伺服器上，減少了執行該過程所需的網絡傳輸寬帶和執行時間。（存儲過程已經對sql語句進行了預編譯，是以其執行速度比在程式裡執行sql語句快很多）

　　2、程式結構方面：從程式的可擴充性看，使用存儲過程會對程式以後的修改帶來友善。比如資料庫的結構改變了，隻需修改相對應的存儲結構，和程式中的調用部分即可。這部分不屬于本文探讨範圍，屬于程式結構設計方面。是以不在此展開。

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

五、查詢語句的優化

　　很多人隻為目的寫出sql語句，而不考慮sql語句的執行效率。在這我隻提供一優化表順序的方法，（sql語句的優化的二十一條軍規以前曾經寫過，有興趣的朋友可以來參考切磋一下）

　　對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選擇表聯結順序

這裡我想強調的是SQL語句的書寫，我不提倡SQL語句裡面連帶太多的業務邏輯，這樣既造成邏輯混亂又給維護造成障礙。前面說過了，很多人可能是單純的寫出SQL語句，可以按照要求檢索出想要的結果，不過為什麼大家的查詢速度不一樣，這就得思考了。我同僚裡大多數人都喜歡使用以下這種方式查詢：

SELECT A.*, B.*, C.*

  FROM A, B, C

 WHERE A.ID = B.ID

   AND B.ID = C.ID

 GROUP BY XX

 ORDER BY XX

要說文法，以上的寫法完全正确。可以咱們來分析一下，将要查詢的表并列，這樣按照資料模組化的做法，需要對表進行全面的掃描，表與表之間的數學關系是一種大家都熟悉的方式：笛卡爾積。我想說到這裡大家就明白了，這裡的計算可以太大了吧，再加上資料量的關系，不但臨時表空白間有被占滿，造成其他操作無法進行的危險外，查詢的速度也是很慢的。表與表之間的關聯關系包括哈希JOIN在内的四、五中關聯關系中我個人認為哈希JOIN大多數情況下比較快(就像哈希表，是數組和連結清單的混合體，夾雜C語言的想法)。

我個人比較提倡以下這種寫法：

SELECT A.*, B.*, C.*

  FROM A LEFT(RIGHT)(OUT) JOIN B ON A.ID = B.ID LEFT(RIGHT)(OUT) C ON B.ID = C.ID

 WHERE A.ID ='001'

       ...

 GROUP BY XX

 ORDER BY XX

這樣查詢進行的時候，是按照要求的對目标表進行順序掃描，減小掃描面積，速度很快。

當然啊，以上的說法需要開發人員具體問題具體分析，關聯的方式和關聯的表順序有講究的，我們拿上面的例子說，如果寫成：

SELECT C.*,A.*, B.*,

  FROM A LEFT(RIGHT)(OUT) JOIN B ON A.ID = B.ID LEFT(RIGHT)(OUT) C ON B.ID = C.ID

 WHERE A.ID ='001'

       ...

 GROUP BY XX

 ORDER BY XX

把C表放到首位，怕是不妥啊，這樣就将優化查詢的初衷給否了。是以SQL語句的編寫既要遵循優化原則也要注重實際，特别是細節。

六、頁面的優化（.aspx）

主要針對幾個頁面屬性

　　1、EnableViewState(頁面的視圖狀态)。如果無特殊要求設定為false。使用ViewState ，每個對象都必須先序列化到 ViewState 中，然後再通過回傳進行反序列化，是以使用 ViewState是沒有代價的。盡量減少使用對象，如果可能，盡量減少放入 ViewState 中的對象的數目。下面情況基本上可以禁用viewstate：

　　（1）頁面控件 （.ascx）

　　（2）頁面不回傳給自身。

　　（3）無需對控件的事件處理。

　　（4）控件沒有動态的或資料綁定的屬性值（或對于每個postpack都在代碼中處理）

　　單個頁面或每個頁面都禁用 ViewState，如下所示：單個頁面：<%@ Page EnableViewState="False" %> 每個頁面：在 web.config 中 <Pages EnableViewState="false" /> EnableSessionState保持預設值即可（如果頁面用到sessionstate它才會占用資源）。EnableViewStateMac如果無安全上的特殊要求，保持預設值。

　　2、Pagelayout.頁面布局模型。建議使用Flowlayout(元素不帶絕對定位屬性添加).Gridlayout(絕對定位屬性)由于采用絕對定位，将會比Flowlayout生産更多的代碼，主要是控件的定位資訊。

　　3、項目釋出的時候切記解除頁面的Debug狀态。

　　4、Html語言的優化。我的建議是熟練掌握Html/Javascript，少用vs.net2003自動生産的代碼，它會自動生成一些無用的html代碼。

　　5、smart navigation設定為true能讓使用者明顯的感覺性能提高。啟用此屬性後對用戶端和服務端影響不大.它能智能涮新需要涮新需涮新的部分.

七、控件的選擇：

　　Html控件和伺服器控件的選擇。伺服器控件帶來的友善和功能上的實作是html控件所不能比拟的。但是是以犧牲伺服器端的資源來取得的。我個人建議：如果html控件達不到所要實作的功能，而且和一些腳本語言（如javascrpt/vbscript）結合也不能實作的話。才會選擇伺服器控件。選擇伺服器控件後，也盡量對其控件優化，如取消一些頁面狀态等（具體看控件的優化）

　　伺服器控件的選擇：主要針對幾個常用資料控件說明一下：

　　DataGrid：自帶最強大的資料顯示控件，内置了對資料的修改、删除、添加、分頁等很多實用功能。如果你隻需對資料顯示的話，盡量不要選擇DataGrid（它把資料都存儲在viewstate中）.也不要使用自帶的分頁功能，microsoft在自動分頁的底層做了很多工作，雖然使用友善了，但性能開銷大了。

　　DataList：比DataGrid功能少了很多。但自定義性強了很多。特有的多行資料顯示，給我們帶來了很多友善。DataGrid能實作的功能，它基本能實作。是以建議使用它。

　　Repeater：功能最少，但自定義性非常強。如果隻需對資料顯示，建議使用。由于減少了很多功能，對伺服器的性能帶來消耗最小。是以，如果是對資料顯示的話，我基本上都是選擇Repeater然後DataList最後DataGrid

　　*盡量選擇html控件。能在用戶端實作的功能就在用戶端實作(熟練掌握javascript)，減少伺服器的壓力。資料控件選擇順序：Repeater、DataList、DataGrid

八、伺服器控件的優化：

　　1、Viewstate

　　控件的viewstate與頁面的viewstate基本是一緻的。用來儲存控件的一些狀态。處理原則和處理頁面的viewstate一樣。有興趣的可以用Datagrid綁定資料測試下viewstate儲存的資料量有多大，它所儲存的資料基本和Datagrid顯示的資料量大小是等同的。

　　2、Ispostpack

　　預設false.需要産生事件的時候才需設定為true.

　　控件的優化，主要看你對此控件的熟悉情況。對控件内部運作的原理越了解，就會對其作出合适的優化。

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