ASP.NET性能優(yōu)化之編碼篇
下面介紹如何在編碼方面進(jìn)行ASP.NET性能優(yōu)化。
ASP.NET性能優(yōu)化之頁面和服務(wù)器控件處理
a) 避免到服務(wù)器的不必要的往返行程
在某些情況下不必使用 ASP.NET 服務(wù)器控件和執(zhí)行回發(fā)事件處理。例如，在 ASP.NET 網(wǎng)頁中驗(yàn)證用戶輸入經(jīng)?？稍跀?shù)據(jù)提交到服務(wù)器之前在客戶端進(jìn)行。通常，如果不需要將信息傳遞到服務(wù)器以進(jìn)行驗(yàn)證或?qū)⑵鋵懭霐?shù)據(jù)存儲(chǔ)區(qū)，請(qǐng)避免使用導(dǎo)致到服務(wù)器的往返行程的代碼，這樣可以提高頁的性能并改善用戶體驗(yàn)。您也可以不執(zhí)行整個(gè)往返行程，而是使用客戶端回調(diào)從服務(wù)器中讀取數(shù)據(jù)。
頁面類實(shí)現(xiàn)ICallbackEventHandler接口，注冊(cè)GetCallbackEventReference方法，也就是ajax的回調(diào)實(shí)現(xiàn)。
針對(duì)一次需要載入很多控件的頁面(載入比較耗時(shí)的頁面)，我們可以使用ajax技術(shù)來達(dá)到一定的頁面訪問性能提升。
b) 使用 Page 對(duì)象的 IsPostBack 屬性來避免對(duì)往返行程執(zhí)行不必要的處理
如果您編寫處理服務(wù)器控件回發(fā)處理的代碼，有時(shí)可能需要代碼僅在***請(qǐng)求頁時(shí)執(zhí)行，而不是每次回發(fā)時(shí)都執(zhí)行。根據(jù)該頁是否是響應(yīng)服務(wù)器控件事件生成的，使用 IsPostBack 屬性有條件地執(zhí)行代碼。
將僅需要***請(qǐng)求頁面時(shí)執(zhí)行的代碼放在IsPostBack條件中運(yùn)行。
c) 只在必要時(shí)保存服務(wù)器控件視圖狀態(tài)
自動(dòng)視圖狀態(tài)管理使服務(wù)器控件可以在往返行程中重新填充它們的屬性值，而您不需要編寫任何代碼。但是，因?yàn)榉?wù)器控件的視圖狀態(tài)在隱藏的窗體字段中往返于服務(wù)器，所以該功能影響性能。了解在哪些情況下視圖狀態(tài)會(huì)有所幫助，在哪些情況下它影響頁的性能，這樣是有幫助的。例如，如果您將服務(wù)器控件綁定到每個(gè)往返行程上的數(shù)據(jù)，因?yàn)榭丶闹禃?huì)在數(shù)據(jù)綁定期間用新值替換，所以保存的視圖狀態(tài)沒有用處。在這種情況下，禁用視圖狀態(tài)可以節(jié)省處理時(shí)間并減少頁的大小。
默認(rèn)情況下，為所有服務(wù)器控件啟用視圖狀態(tài)。若要禁用它，請(qǐng)將控件的 EnableViewState 屬性設(shè)置為 false。
還可以使用 @ Page 指令禁用整個(gè)頁的視圖狀態(tài)。當(dāng)您不從頁回發(fā)到服務(wù)器時(shí)，這將十分有用。
@ Control 指令中還支持 EnableViewState 屬性以指定是否為用戶控件啟用視圖狀態(tài)。
查看視圖狀態(tài)的方法：
若要分析服務(wù)器控件在頁中使用的視圖狀態(tài)的大小，請(qǐng)通過將 trace="true" 屬性包含在 @ Page 指令中啟用對(duì)該頁的跟蹤。然后在跟蹤輸出中，查看“控件層次結(jié)構(gòu)”表的“Viewstate”列。
下面情況基本上可以禁用viewstate：
（1）頁面控件 （.ascx）
（2）頁面不回傳給自身。
（3）無需對(duì)控件的事件處理。
（4）控件沒有動(dòng)態(tài)的或數(shù)據(jù)綁定的屬性值（或?qū)τ诿總€(gè)postpack都在代碼中處理）
d) 除非有特殊的原因要關(guān)閉緩沖，否則使其保持打開狀態(tài)
禁用 ASP.NET 網(wǎng)頁的緩沖會(huì)導(dǎo)致大量的性能開銷。
e) Server.Transfer和Response.Redirect的選擇
Response.Redirect 簡(jiǎn)單地告訴瀏覽器訪問另一個(gè)頁面。Server.Transfer 有利于減少服務(wù)器請(qǐng)求，保持地址欄 URL 不變，允許你將 query string 和 form 變量傳遞到另一個(gè)頁面，可以隱藏url中傳遞的參數(shù)。
Response.Redirect可以跨站點(diǎn)跳轉(zhuǎn)，Server.Transfer只能同站點(diǎn)跳轉(zhuǎn)。
微軟建議：
使用 Transfer Server 對(duì)象或跨頁發(fā)送的方法在同一個(gè)應(yīng)用程序中的不同 ASP.NET 頁之間重定向
如無特殊要求，應(yīng)優(yōu)先選擇Server.Transfer進(jìn)行頁面跳轉(zhuǎn)
ASP.NET性能優(yōu)化之?dāng)?shù)據(jù)訪問
a) 將 SQL Server 和存儲(chǔ)過程用于數(shù)據(jù)訪問
在 .NET Framework 提供的所有數(shù)據(jù)訪問方法中，使用 SQL Server 進(jìn)行數(shù)據(jù)訪問是生成高性能、可縮放 Web 應(yīng)用程序的推薦選擇。使用托管 SQL Server 提供程序時(shí)，可通過盡可能使用編譯的存儲(chǔ)過程而不是 SQL 命令獲得額外的性能提高。
（僅針對(duì)數(shù)據(jù)庫選擇SQL Server，數(shù)據(jù)庫為其他的可以忽略此選項(xiàng)）
b) 將 SqlDataReader 類用于快速只進(jìn)數(shù)據(jù)游標(biāo)
SqlDataReader 類提供了從 SQL Server 數(shù)據(jù)庫檢索的只進(jìn)數(shù)據(jù)流。如果您可以在 ASP.NET 應(yīng)用程序中使用只讀流，則 SqlDataReader 類提供比 DataSet 類更高的性能。SqlDataReader 類使用 SQL Server 的本機(jī)網(wǎng)絡(luò)數(shù)據(jù)傳輸格式從數(shù)據(jù)庫連接直接讀取數(shù)據(jù)。例如，當(dāng)綁定到 SqlDataSource 控件時(shí)，通過將 DataSourceMode 屬性設(shè)置為 DataReader，您將獲得更好的性能。（使用數(shù)據(jù)讀取器會(huì)導(dǎo)致某些功能的丟失。）另外，SqlDataReader 類實(shí)現(xiàn) IEnumerable 接口，該接口也使您可以將數(shù)據(jù)綁定到服務(wù)器控件。
(僅針對(duì)數(shù)據(jù)庫選擇SQL Server，數(shù)據(jù)庫為其他的可以忽略此選項(xiàng)) MySql中對(duì)應(yīng)MySqlDataReader，根據(jù)需要選擇。
c) 盡可能緩存數(shù)據(jù)和頁輸出
ASP.NET 提供了一些機(jī)制，它們會(huì)在不需要為每個(gè)頁請(qǐng)求動(dòng)態(tài)計(jì)算頁輸出或數(shù)據(jù)時(shí)緩存這些頁輸出或數(shù)據(jù)。另外，通過設(shè)計(jì)要進(jìn)行緩存的頁和數(shù)據(jù)請(qǐng)求（特別是在站點(diǎn)中預(yù)期將有較大通訊量的區(qū)域），可以優(yōu)化這些頁的性能。與使用 .NET Framework 的任何其他功能相比，適當(dāng)?shù)厥褂镁彺婵梢愿玫靥岣哒军c(diǎn)的性能。
在使用 ASP.NET 緩存時(shí)，應(yīng)注意以下事項(xiàng)。首先，不要緩存太多項(xiàng)。緩存每個(gè)項(xiàng)都有內(nèi)存開銷。不要緩存容易重新計(jì)算和很少使用的項(xiàng)。其次，給緩存項(xiàng)分配的有效期不要太短。很快到期的項(xiàng)會(huì)導(dǎo)致緩存中不必要的周轉(zhuǎn)，并且會(huì)導(dǎo)致額外的代碼清除和垃圾回收工作。使用與“ASP.NET Applications”性能對(duì)象關(guān)聯(lián)的“Cache Total Turnover Rate”（緩存總流通率）性能計(jì)數(shù)器，您可以監(jiān)視緩存中由于項(xiàng)到期而導(dǎo)致的周轉(zhuǎn)。高周轉(zhuǎn)率可能說明存在問題，特別是當(dāng)項(xiàng)在到期前被移除時(shí)。（這種情況有時(shí)稱作內(nèi)存壓力。）
可以考慮把靜態(tài)的、變化不大的或者不經(jīng)常變化需要?jiǎng)討B(tài)加載的內(nèi)容放入控件中，使用緩存技術(shù)。
< %@ OutputCache Duration="100" VaryByParam="none" %>
d) 適當(dāng)?shù)厥褂?SQL 緩存依賴項(xiàng)
ASP.NET 同時(shí)支持基于表的輪詢和查詢通知，具體取決于所使用的 SQL Server 的版本。所有 SQL Server 版本都支持基于表的輪詢。在基于表的輪詢中，如果表中的任何內(nèi)容發(fā)生更改，所有偵聽器都會(huì)失效。這可能導(dǎo)致應(yīng)用程序中不必要的改動(dòng)。建議不要將基于表的輪詢用于具有許多頻繁更改的表。例如，建議將基于表的輪詢用于很少更改的目錄表。建議不要將基于表的輪詢用于訂單表，訂單表具有更頻繁的更新。SQL Server 2005 支持查詢通知。查詢通知支持特定查詢，從而減少在表更改時(shí)發(fā)送的通知數(shù)量。雖然它比基于表的輪詢提供更好的性能，但是它無法擴(kuò)展到適應(yīng)數(shù)千個(gè)查詢。
(僅針對(duì)數(shù)據(jù)庫選擇SQL Server，數(shù)據(jù)庫為其他的可以忽略此選項(xiàng))
e) 使用數(shù)據(jù)源分頁和排序而不是 UI（用戶界面）分頁和排序
DetailsView 和 GridView 等數(shù)據(jù)控件的 UI 分頁功能可用于支持 ICollection 接口的任何數(shù)據(jù)源對(duì)象。對(duì)于每個(gè)分頁操作，數(shù)據(jù)控件查詢數(shù)據(jù)源的整個(gè)數(shù)據(jù)集并選擇要顯示的行，并放棄其余的數(shù)據(jù)。如果數(shù)據(jù)源實(shí)現(xiàn) DataSourceView 并且 CanPage 屬性返回 true，則數(shù)據(jù)控件將使用數(shù)據(jù)源分頁而不是 UI 分頁。在這種情況下，數(shù)據(jù)控件僅查詢每個(gè)分頁操作需要的行。因此，數(shù)據(jù)源分頁比 UI 分頁更高效。只有 ObjectDataSource 數(shù)據(jù)源控件才支持?jǐn)?shù)據(jù)源分頁。若要在其他數(shù)據(jù)源控件上啟用數(shù)據(jù)源分頁，必須從該數(shù)據(jù)源控件繼承并修改其行為。
f) 平衡事件驗(yàn)證的安全性受益和性能開銷
從 System.Web.UI.WebControls 和 System.Web.UI.HtmlControls 類派生的控件可以驗(yàn)證事件是否源自該控件所呈現(xiàn)的用戶界面。這樣有助于防止控件響應(yīng)偽造的事件通知。例如，DetailsView 控件可以防止 Delete（刪除）調(diào)用（控件中本質(zhì)上不支持該調(diào)用）的處理以及被操縱而刪除數(shù)據(jù)。此驗(yàn)證會(huì)帶來一定的性能開銷?？梢允褂?EnableEventValidation 配置元素和 RegisterForEventValidation 方法控制此行為。驗(yàn)證的開銷取決于頁上的控件數(shù)量，并在幾個(gè)百分點(diǎn)范圍內(nèi)。
強(qiáng)烈建議不要禁用事件驗(yàn)證。在禁用事件驗(yàn)證之前，應(yīng)該確保不會(huì)構(gòu)造任何可能對(duì)應(yīng)用程序具有意外影響的回發(fā)。
g) 除非必要，否則避免使用視圖狀態(tài)加密
視圖狀態(tài)加密會(huì)阻止用戶能夠讀取隱藏視圖狀態(tài)字段中的值。典型情況是在 DataKeyNames 屬性中帶有一個(gè)標(biāo)識(shí)符字段的 GridView 控件。標(biāo)識(shí)符字段是協(xié)調(diào)對(duì)記錄的更新所必需的。由于不想要標(biāo)識(shí)符對(duì)用戶可見，因此可以加密視圖狀態(tài)。但是，加密對(duì)于初始化具有恒定的性能開銷，并具有取決于被加密的視圖狀態(tài)大小的附加開銷。加密為每次頁加載而設(shè)置，因此在每次頁加載時(shí)都會(huì)發(fā)生相同的性能影響。
h) 使用 SqlDataSource 緩存、排序和篩選
如果 SqlDataSource 控件的 DataSourceMode 屬性設(shè)置為 DataSet，則 SqlDataSource 能夠緩存查詢產(chǎn)生的結(jié)果集。如果以這種方式緩存數(shù)據(jù)，則控件的篩選和排序操作（使用 FilterExpression 和 SortParameterName 屬性進(jìn)行配置）將使用緩存的數(shù)據(jù)。在許多情況下，如果緩存整個(gè)數(shù)據(jù)集，并使用 FilterExpression 和 SortParameterName 屬性進(jìn)行排序和篩選，而不是使用帶“WHERE”和“SORT BY”子句的 SQL 查詢（對(duì)于這些查詢，每個(gè)選擇操作都要訪問數(shù)據(jù)庫），應(yīng)用程序會(huì)運(yùn)行得更快。
(根據(jù)具體控件，僅支持部分?jǐn)?shù)據(jù)庫)
ASP.NET性能優(yōu)化之編碼實(shí)踐
a) 不要依賴代碼中的異常
異常會(huì)大大地降低性能，所以您應(yīng)該避免將它們用作控制正常程序流的方式。如果有可能檢測(cè)到代碼中可能導(dǎo)致異常的狀態(tài)，請(qǐng)執(zhí)行這種操作，而不要捕捉異常本身和處理該狀態(tài)。常見的代碼檢測(cè)方案包括：檢查 null，將一個(gè)值分配給將分析為數(shù)值的 String，或在應(yīng)用數(shù)學(xué)運(yùn)算前檢查特定值。
b) 在托管代碼中重寫調(diào)用密集型的 COM 組件
.NET Framework 提供了一個(gè)簡(jiǎn)單的方法與傳統(tǒng)的 COM 組件進(jìn)行交互。其優(yōu)點(diǎn)是可以在保留現(xiàn)有 COM 組件投資的同時(shí)利用 .NET 的功能。但是在某些情況下，保留舊組件的性能開銷使得將組件遷移到托管代碼是值得的。每一情況都是不一樣的，決定是否需要遷移組件的***方法是對(duì)網(wǎng)站運(yùn)行性能測(cè)量。建議研究一下如何將經(jīng)常調(diào)用的任何 COM 組件遷移到托管代碼。
許多情況下不可能將舊式組件遷移到托管代碼，特別是在最初遷移 Web 應(yīng)用程序時(shí)。在這種情況下，***的性能障礙之一是將數(shù)據(jù)從非托管環(huán)境封送到托管環(huán)境。因此，在交互操作中，請(qǐng)?jiān)谌魏我欢藞?zhí)行盡可能多的任務(wù)，然后進(jìn)行單個(gè)調(diào)用而不是一系列小調(diào)用。例如，公共語言運(yùn)行庫中的所有字符串都是 Unicode 的，所以應(yīng)在調(diào)用托管代碼之前將組件中的所有字符串轉(zhuǎn)換成 Unicode 格式。
一旦處理完任何 COM 對(duì)象或本機(jī)資源就釋放它們。這樣，其他請(qǐng)求就能夠使用它們，并且***限度地減少了因稍后請(qǐng)求垃圾回收器釋放它們所引起的性能問題。
c) 避免單線程單元 (STA) COM 組件
默認(rèn)情況下，ASP.NET 不允許 STA COM 組件在頁內(nèi)運(yùn)行。若要運(yùn)行它們，必須在 .aspx 文件內(nèi)將 ASPCompat=true 屬性包含在 @ Page 指令中。這樣就將頁執(zhí)行用的線程池切換到 STA 線程池，而且使 HttpContext 和其他內(nèi)置對(duì)象可用于 COM 對(duì)象。避免使用 STA COM 組件是一種性能優(yōu)化，因?yàn)樗苊饬藢⒍嗑€程單元 (MTA) 封送到 STA 線程的任何調(diào)用。
如果必須使用 STA COM 組件，則應(yīng)避免在執(zhí)行期間進(jìn)行大量調(diào)用，并嘗試在每次調(diào)用期間發(fā)送盡可能多的信息。***機(jī)制是推遲對(duì)象的創(chuàng)建，推薦的做法是僅在需要時(shí)或者在 Page_Load 方法中構(gòu)造 COM 組件和外部資源。
永遠(yuǎn)不要將 STA COM 組件存儲(chǔ)在可以由構(gòu)造它們的線程以外的其他線程訪問的共享資源（如緩存或會(huì)話狀態(tài)）里。即使 STA 線程調(diào)用 STA COM 組件，也只有構(gòu)造此 STA COM 組件的線程能夠?yàn)樵撜{(diào)用服務(wù)，而這要求封送處理對(duì)創(chuàng)建者線程的調(diào)用。此封送處理可能產(chǎn)生重大的性能損失和可伸縮性問題。在這種情況下，請(qǐng)考慮使 COM 組件成為 MTA COM 組件或在托管代碼中重寫該組件。
本文來自shllove的專欄：《ASP.NET性能優(yōu)化整理》。【編輯推薦】
