ASP.NET程式性能優化的七個方面

一、資料庫操作

1、用完馬上關閉資料庫連接配接

　　通路資料庫資源需要建立連接配接、打開連接配接和關閉連接配接幾個操作。這些過程需要多次與資料庫交換資訊以通過身份驗證，比較耗費伺服器資

源。ASP.NET中提供了連接配接池（Connection Pool）改善打開和關閉資料庫對性能的影響。系統将使用者的資料庫連接配接放在連接配接池中，需要時取出，關閉時收回連接配接，等待下一次的連接配接請求。

　　 連接配接池的大小是有限的，如果在連接配接池達到最大限度後仍要求建立連接配接，必然大大影響性能。是以，在建立資料庫連接配接後隻有在真正需要操作時才打開連接配接，使用完畢後馬上關閉，進而盡量減少資料庫連接配接打開的時間，避免出現超出連接配接限制的情況。

用（推薦）

using(SqlConnection Conn=new SqlConnection(connstr))

{}//不必顯示關閉

或

try{conn.Open();}

catch{}

finally{conn.Close();}

2、盡量使用存儲過程，并優化查詢語句

　　存儲過程是存儲在伺服器上的一組預編譯的SQL語句，類似于DOS系統中的批處理檔案。存儲過程具有對資料庫立即通路的功能，資訊處理極為迅速。使用存儲過程可以避免對指令的多次編譯，在執行一次後其執行規劃就駐留在高速緩存中，以後需要時隻需直接調用緩存中的二進制代碼即可。在 .NET Framework 提供的所有資料通路方法中，基于 SQL Server 的資料通路是生成高性能、可縮放 Web 應用程式的推薦選擇。使用托管 SQL Server 提供程式時，可通過使用編譯的存儲過程而不是特殊查詢獲得額外的性能提高。

　　另外，存儲過程在伺服器端運作，獨立于ASP.NET程式，便于修改，最重要的是它可以減少資料庫操作語句在網絡中的傳輸。

　　優化查詢語句

　　ASP.NET中ADO連接配接消耗的資源相當大，SQL語句運作的時間越長，占用系統資源的時間也越長。是以，盡量使用優化過的SQL語句以減少執行時間。比如，不在查詢語句中包含子查詢語句，盡量隻傳回有用的資料、字段，充分利用索引等。

3、隻讀資料通路用SqlDataReader，不要使用DataSet

　　SqlDataReader 類提供了一種讀取從 SQL Server 資料庫檢索的隻進資料流的方法。如果當建立 ASP.NET 應用程式時出現允許您使用它的情況，則 SqlDataReader 類提供比 DataSet 類更高的性能。情況之是以這樣，是因為 SqlDataReader 使用 SQL Server 的本機網絡資料傳輸格式從資料庫連接配接直接讀取資料。另外，SqlDataReader 類實作 IEnumerable 接口，該接口也允許您将資料綁定到伺服器控件。DataSet作為一個功能強大的、支援離線的資料庫，其對性能的開銷也相對較大。

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

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

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

4、資料的綁定DataBinder

一般的綁定方法<%# DataBinder.Eval(Container.DataItem, "字段名") %>

用DataBinder.eval 綁定不必關心資料來源(read或dataset)。不必關心資料的類型eval會把這個資料對象轉換為一個字元串。在底層綁定做了很多工作，使用了反射性能。正因為使用友善了，但卻影響了資料性能。

來看下<%# DataBinder.Eval(Container.DataItem, "字段名") %>。當于dataset綁定時，DataItem其實式一個DataRowView（如果綁定的是一個資料讀取器（dataread）它就是一個IdataRecord。）是以直接轉換成DataRowView的話，将會給性能帶來很大提升。

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

對資料的綁定建議使用<%# ctype(Container.DataItem,DataRowView).Row("字段名") %>。使用時注意兩個方面：

1.需在頁面添加<%@ Import namespace="System.Data"%>.

2.注意字段名的大小寫（要特别注意）。如果和查詢的不一緻，在某些情況下會導緻比<%# DataBinder.Eval(Container.DataItem, "字段名") %>還要慢。如果想進一步提高速度，可采用<%# ctype(Container.DataItem,DataRowView).Row(0) %>的方法。不過其可讀性不高。

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

5、傳回多個結果集

無論SqlDataReader還是datset，傳回多個結果集，然後用rd.NextResult()或ds.Tables[i]來分别處理資料，減少重複連接配接資料庫的次數。同時盡量用比較高效的SQL代替後續複雜的DataSet二次加工。

二、頁面優化

1、不使用不必要的伺服器控件（Server Control）

ASP.net中，大量的伺服器端控件友善了程式開發，但也可能帶來性能的損失，因為使用者每操作一次伺服器端控件，就産生一次與伺服器端的往返過程。是以，非必要，應當少使用Server Control。還有許多其他情況，在這些情況中呈現或資料綁定比使用伺服器控件更有效，甚至是在使用伺服器控件模闆時。但是，如果要以程式設計方式操作伺服器控件的屬性、處理伺服器控件事件或利用視圖狀态儲存，則使用伺服器控件是适當的。

是以，盡量選擇html控件。能在用戶端實作的功能就在用戶端實作(熟練掌握javascript)，減少伺服器的壓力。

2、不使用不必要的ViewState

預設情況下，ASP.Net對所有的Server Control都啟用了ViewState（視圖狀态）。但ViewState需要在用戶端儲存一些資訊，這會造成性能的消耗。當必須使用Server Control時，可以考慮禁止ViewState。

隻在必要時儲存伺服器控件視圖狀态。自動視圖狀态管理是伺服器控件的功能，該功能使伺服器控件可以在往返過程上重新填充它們的屬性值（您不需要編寫任何代碼）。但是，因為伺服器控件的視圖狀态在隐藏的窗體字段中往返于伺服器，是以該功能确實會對性能産生影響。您應該知道在哪些情況下視圖狀态會有所幫助，在哪些情況下它影響頁的性能。例如，如果您将伺服器控件綁定到每個往返過程上的資料，則将用從資料綁定操作獲得的新值替換儲存的視圖狀态。在這種情況下，禁用視圖狀态可以節省處理時間。

預設情況下，為所有伺服器控件啟用視圖狀态。若要禁用視圖狀态，請将控件的 EnableViewState 屬性設定為 false，如下面的 DataGrid 伺服器控件示例所示。

<asp:datagrid EnableViewState="false" runat="server"/>

您還可以使用 @ Page 指令禁用整個頁的視圖狀态。當您不從頁回發到伺服器時，這将十分有用： <%@ Page EnableViewState="false" %>

注意 @ Control 指令中也支援 EnableViewState 屬性，該指令允許您控制是否為使用者控件啟用視圖狀态。

若要分析頁上伺服器控件使用的視圖狀态的數量，請（通過将 trace="true" 屬性包括在 @ Page 指令中）啟用該頁的跟蹤并檢視 Control Hierarchy 表的 Viewstate 列。

3、避免到伺服器的不必要的往返過程

　　雖然您很可能希望盡量多地使用 Web 窗體頁架構的那些節省時間和代碼的功能，但在某些情況下卻不宜使用 ASP.NET 伺服器控件和回發事件處理。

　　通常，隻有在檢索或存儲資料時，您才需要啟動到伺服器的往返過程。多數資料操作可在這些往返過程間的用戶端上進行。例如，從 HTML 窗體驗證使用者輸入經常可在資料送出到伺服器之前在用戶端進行。通常，如果不需要将資訊傳遞到伺服器以将其存儲在資料庫中，那麼您不應該編寫導緻往返過程的代碼。

　　如果您開發自定義伺服器控件，請考慮讓它們為支援 ECMAScript 的浏覽器呈現用戶端代碼。通過以這種方式使用伺服器控件，您可以顯著地減少資訊被不必要的發送到 Web 伺服器的次數。

　　使用 Page.IsPostBack 避免對往返過程執行不必要的處理

　　如果您編寫處理伺服器控件回發處理的代碼，有時可能需要在首次請求頁時執行其他代碼，而不是當使用者發送包含在該頁中的 HTML 窗體時執行的代碼。根據該頁是否是響應伺服器控件事件生成的，使用 Page.IsPostBack 屬性有條件地執行代碼。例如，下面的代碼示範如何建立資料庫連接配接和指令，該指令在首次請求該頁時将資料綁定到 DataGrid 伺服器控件。

void Page_Load(Object sender, EventArgs e)

{

if(!Page.IsPostBack)

{}

}

　　由于每次請求時都執行 Page_Load 事件，上述代碼檢查 IsPostBack 屬性是否設定為 false。如果是，則執行代碼。如果該屬性設定為true，則不執行代碼。

　　注意 如果不運作這種檢查，回發頁的行為将不更改。Page_Load 事件的代碼在執行伺服器控件事件之前執行，但隻有伺服器控件事件的結果才可能在輸出頁上呈現。如果不運作該檢查，仍将為 Page_Load 事件和該頁上的任何伺服器控件事件執行處理。

4、當不使用會話狀态時禁用它，并且程式開發中盡量少用Session

　　并不是所有的應用程式或頁都需要針對于具體使用者的會話狀态，您應該對任何不需要會話狀态的應用程式或頁禁用會話狀态。

　　若要禁用頁的會話狀态，請将 @ Page 指令中的 EnableSessionState 屬性設定為 false。例如: <%@ Page EnableSessionState="false" %>

　　注意 如果頁需要通路會話變量，但不打算建立或修改它們，則将 @ Page 指令中的 EnableSessionState 屬性設定為 ReadOnly。

　　 若要禁用應用程式的會話狀态，請在應用程式 Web.config 檔案的 sessionstate 配置節中将 mode 屬性設定為 off。例如:<sessionstate mode="off" />

5、合理使用DataGrid(在asp.net2.0中為GridView)控件

　　DataGrid控件帶有最強大的資料顯示功能，還内置了對資料的修改、删除、添加、分頁等很多功能。如果隻需簡單的顯示資料， DataGrid并非最佳選擇。DataGrid控件的分頁功能，資料的存儲方式（存儲在viewstate中）等，雖然讓程式開發者使用友善快捷，但由此産生的性能開銷不容小視。

　　DataList控件比DataGrid功能少了很多。但自定義性強了很多。特有的多行資料顯示還是比較友善的。DataGrid能實作的功能，它基本能實作。

　　Repeater控件功能最少，但自定義性非常強。由于減少了很多功能，對伺服器的性能帶來消耗最小。

　　是以，在隻需簡單顯示資料清單時，選擇Repeater或DataList控件同樣可以達到目的，而且減輕了性能上的開銷。

建議選擇順序：Repeater然後DataList最後DataGrid（GridView）

6、對資料進行分頁

　　ASP.NET的DataGrid(在asp.net2.0中為GridView)有一個非常有用的功能：分頁。如果DataGrid允許分頁，在某一時刻它隻下載下傳某一頁的資料，另外，它有一個資料分頁的浏覽導航欄，它讓你可以選擇浏覽某一頁，而且每次隻下載下傳一頁的資料。

　　但是它有一個小小的缺點，就是你必須把所有的資料都綁定到DataGrid中。也就是說，你的資料層必須傳回所有的資料，然後DataGrid再根據目前頁過濾出目前頁所需要的資料顯示出來。如果有一個一萬條記錄的結果集要用DataGrid進行分頁，假設DataGrid每頁隻顯示25條資料，那就意味着每次請求都有9975條資料都是要丢棄的。每次請求都要傳回這麼大的資料集，對應用程式的性能影響是非常大的。

　　一個好的解決方案是寫一個分頁的存儲過程，

如：

CREATE PROCEDURE dbo.sp_DataPages

@Sql nVARCHAR(2000),

@PK varchar(50), --主鍵字段名（可以是任何資料類型；不能，并且也不需要帶表名字首，如：不可以是users.id）

@Order varchar(50), --排序方式（帶desc或asc，可以是多個組合；不能，并且也不需要帶表名字首，如：不可以是users.id desc）

@Page int,

@PageSize int = 30

AS

set nocount on

DECLARE @Str nVARCHAR(4000)

if(@Page=1)

SET @Str= 'Select Top '+ CAST((@PageSize) As VARCHAR(20)) + ' * From ('+ @Sql + ') As table1 Order By table1.' + @Order

else

SET @Str= 'Select Top '+ CAST((@PageSize) As VARCHAR(20)) + ' * From ('+ @Sql + ') As table1 Where table1.' + @PK + ' Not In (Select Top ' + CAST((@PageSize*(@Page-1)) AS VARCHAR(20)) + ' ' + @PK + ' From (' + @Sql + ') As table2 Order By table2.' + @Order + ' ) Order By table1.' + @Order

--print @str

--exec (@Str)

EXEC sp_ExecuteSql @Str

set nocount off

GO

或者，使用sql server 2005中的row_number()函數

declare @sql varchar(8000)

set @sql='select *'

+' from'

+' ('

+' select row_number() over (order by id desc) as rowNumber,*'

+' from Users'

+' where id>0 and name<>'''''

+' )'

+' as table1'

+' where rowNumber between '+str((@page-1)*@pagesize+1)+' AND '+str(@page*@pagesize)

+' order by id desc'

--exec (@sql)

EXEC sp_ExecuteSql @sql

(小技巧：将記錄總數保為Cache或Session來提高分頁性能。)

7、不要禁用 Web 窗體頁的緩沖

除非有特殊的原因要關閉緩沖，否則使其保持打開。禁用 Web 窗體頁的緩沖會導緻大量的性能開銷。

啟用頁面輸出的緩沖區（Buffer）

如果Buffer的機制被關閉，可以用下面的方法打開。

使用程式打開頁面輸出緩存：

Response.BufferOutput = true;

使用@Page開關打開頁面輸出緩沖機制：

<%@ Page Buffer = "true" %>

使用Web.config或Machine.config配置檔案的<pages>節點：

<pages buffer="true"/>

8、設定page的smart navigation屬性

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

在大多數情況下不要在代碼中設定該屬性。

在 .aspx 檔案的 @ Page 指令中将 SmartNavigation 屬性設定為 true。請求該頁時，動态生成的類将設定該屬性。

Internet Explorer 5 或更高版本浏覽器請求頁時（或稍後），智能導航将通過執行下列功能提高使用者對該頁的操作能力：

消除導航導緻的閃爍。

從一頁移動到另一頁時保持滾動位置。

保持導航之間的元素焦點。

在浏覽器的曆史記錄中隻保留最後一頁的狀态。

智能導航最适用于需要頻繁回發，但是其内容在傳回時不會發生顯著更改的 ASP.NET 頁。在決定是否将該屬性設定為 true 時，請仔細考慮這一點。

三、c#（或vb.net）程式改進

1、使用值類型的ToString方法

　　在連接配接字元串時，經常使用"+"号直接将數字添加到字元串中。這種方法雖然簡單，也可以得到正确結果，但是由于涉及到不同的資料類型，數字需要通過裝箱操作轉化為引用類型才可以添加到字元串中。但是裝箱操作對性能影響較大，因為在進行這類處理時，将在托管堆中配置設定一個新的對象，原有的值複制到新建立的對象中。

　　使用值類型的ToString方法可以避免裝箱操作，進而提高應用程式性能。

int num=1;

string str="go"+num.ToString();

2、運用StringBuilder類

　　String類對象是不可改變的，對于String對象的重新指派在本質上是重新建立了一個String對象并将新值賦予該對象，其方法ToString對性能的提高并非很顯著。

　　在處理字元串時，最好使用StringBuilder類，其.NET 命名空間是System.Text。該類并非建立新的對象，而是通過Append，Remove，Insert等方法直接對字元串進行操作，通過ToString方法傳回操作結果。

　　其定義及操作語句如下所示：

int num;

System.Text.StringBuilder str = new System.Text.StringBuilder(); //建立字元串

str.Append(num.ToString()); //添加數值num

Response.Write(str.ToString); //顯示操作結果

3、使用 HttpServerUtility.Transfer 方法在同一應用程式的頁面間重定向

　　采用 Server.Transfer 文法，在頁面中使用該方法可避免不必要的用戶端重定向（Response.Redirect）。

4、避免使用ArrayList。

因為任何對象添加到ArrayList都要封箱為System.Object類型，從ArrayList取出資料時，要拆箱回實際的類型。建議使用自定義的集合類型代替ArrayList。asp.net 2.0提供了一個新的類型，叫泛型，這是一個強類型，使用泛型集合就可以避免了封箱和拆箱的發生，提高了性能。

5、使用HashTale代替其他字典集合類型

（如StringDictionary,NameValueCollection,HybridCollection），存放少量資料的時候可以使用HashTable.

6、為字元串容器聲明常量，不要直接把字元封裝在雙引号" "裡面。

//避免

MyObject obj = new MyObject();

obj.Status = "ACTIVE";

//推薦

const string C_STATUS = "ACTIVE";

MyObject obj = new MyObject();

obj.Status = C_STATUS;

7、不要用ToUpper(),ToLower()轉換字元串進行比較，用String.Compare代替，它可以忽略大小寫進行比較.

例：

const string C_VALUE = "COMPARE";

if (String.Compare(sVariable, C_VALUE, true) == 0)

{

Console.Write( "相同");

}

也可以用str == String.Empty或者str.Length == 0判斷是否為空。(注意判斷輸入資料的長度，可防止sql注入式攻擊)

将String對象的Length屬性與0比較是最快的方法，避免不必要的調用 ToUpper 或 ToLower 方法。

8、類型轉化Int32.TryParse()優于Int32.Parse()優于Convert.ToInt32()。

建議.NET1.1下用Int32.Parse()；.NET2.0用Int32.TryParse()。

因為：

Convert.ToInt32 會把最終的解析工作代理給 Int32.Parse；

Int32.Parse 會把最終的解析工作代理給Number.ParseInt32；

Int32.TryParse 會把最終的解析工作代理給Number.TryParseInt32。

9、如果隻是從XML對象讀取資料，用隻讀的XPathDocument代替XMLDocument,可以提高性能

//避免

XmlDocument xmld = new XmlDocument();

xmld.LoadXml(sXML);

txtName.Text = xmld.SelectSingleNode( "/packet/child").InnerText;

//推薦

XPathDocument xmldContext = new XPathDocument(new StringReader(oContext.Value));

XPathNavigator xnav = xmldContext.CreateNavigator();

XPathNodeIterator xpNodeIter = xnav.Select( "packet/child");

iCount = xpNodeIter.Count;

xpNodeIter = xnav.SelectDescendants(XPathNodeType.Element, false);

while(xpNodeIter.MoveNext())

{

sCurrValues += xpNodeIter.Current.Value+ ",";

}

10、避免在循環體裡聲明變量，應該在循環體外聲明變量，在循環體裡初始化。

C#程式開發要遵循的一個基本原則就是避免不必要的對象建立

//避免

for(int i=0; i<10; i++)

{

SomeClass objSC = new SomeClass();

}

//推薦

SomeClass objSC = null;

for(int i=0; i <10; i++)

{

objSC = new SomeClass();

}

11、捕獲指定的異常，不要使用通用的System.Exception.

//避免

try

{

<some logic>

}

catch(Exception exc)

{

<Error handling>

}

//推薦

try

{

<some logic>

}

catch(System.NullReferenceException exc)

{

<Error handling>

}

catch(System.ArgumentOutOfRangeException exc)

{

<Error handling>

}

catch(System.InvalidCastException exc)

{

<Error handling>

}

12、使用Try...catch...finally時， 要在finally裡釋放占用的資源如連接配接，檔案流等

不然在Catch到錯誤後占用的資源不能釋放。

try

{}

catch

{}

finally

{

conntion.close();

}

13、不要用Exception控制程式流程

有些程式員可能會使用異常來實作一些流程控制。例如：

try{

result=100/num;

}

Catch(Exception e)

{

result=0;

}

但實際上，Exception是非常消耗系統性能的。除非必要，不應當使用異常控制來實作程式流程。上面的代碼應當寫為：

if(num!=0)

result=100/num;

else

result=0;

14、避免使用遞歸調用和嵌套循環，使用他們會嚴重影響性能，在不得不用的時候才使用。

15、禁用VB.net和Jscript動态資料類型

應當始終顯示地申明變量資料類型，這能夠節約程式的執行時間。以往，開發人員喜歡使用 Visual Basic、VBScript 和 JScript 的原因之一就是它們所謂“無類型”的性質。變量不需要顯式類型聲明，并能夠簡單地通過使用來建立它們。當從一個類型到另一個類型進行配置設定時，轉換将自動執行。不過，這種便利會大大損害應用程式的性能。

如：

為了獲得最佳的性能，當聲明 JScript .NET 變量時，請為其配置設定一個類型。例如，var A : String;

四、使用緩存

1、使用Output Cache緩存資料

提供緩存功能是ASP.net中非常強大的一種功能。曾看到過某些評測說：ASP.net程式的性能比SUN的JSP應用程式性能快上幾倍，實際上，該評測程式非常重要的一點就是使用了很多ASP.net的緩存功能。

　　如果你的元件是要在Asp.net應用程式中運作，你隻要把System.Web.dll引用到你的項目中就可以了。然後用HttpRuntime.Cache屬性就可通路Cache了（也可以通過Page.Cache或HttpContext.Cache通路）。

　　有以下幾條緩存資料的規則。第一，資料可能會被頻繁的被使用，這種資料可以緩存。第二，資料的通路頻率非常高，或者一個資料的通路頻率不高，但是它的生存周期很長，這樣的資料最好也緩存起來。第三是一個常常被忽略的問題，有時候我們緩存了太多資料，通常在一台X86的機子上，如果你要緩存的資料超過800M的話，就會出現記憶體溢出的錯誤。是以說緩存是有限的。換名話說，你應該估計緩存集的大小，把緩存集的大小限制在10以内，否則它可能會出問題。在Asp.net中，如果緩存過大的話也會報記憶體溢出錯誤，特别是如果緩存大的DataSet對象的時候。

　　這裡有幾個你必須了解的重要的緩存機制。首先是緩存實作了“最近使用”原則（ a least-recently-used algorithm），當緩存少的時候，它會自動的強制清除那些無用的緩存。其次 “條件依賴”強制清除原則（expiration dependencies），條件可以是時間，關鍵字和檔案。以時間作為條件是最常用的。在asp.net2.0中增加一更強的條件，就是資料庫條件。當資料庫中的資料發生變化時，就會強制清除緩存。

　　使用 ASP.NET 緩存機制有兩點需要注意。首先，不要緩存太多項。緩存每個項均有開銷，特别是在記憶體使用方面。不要緩存容易重新計算和很少使用的項。其次，給緩存的項配置設定的有效期不要太短。很快到期的項會導緻緩存中不必要的周轉，并且經常導緻更多的代碼清除和垃圾回收工作。若關心此問題，請監視與 ASP.NET Applications 性能對象關聯的 Cache Total Turnover Rate 性能計數器。高周轉率可能說明存在問題，特别是當項在到期前被移除時。這也稱作記憶體壓力。

切記：

應該：

應該緩存那些經常被通路、同時變化頻率不大的資料

應該緩存整個應用程式都要使用的設定或對象，但這些設定和對象必須在其生存期内不會變化

不應該：

不要緩存個人資訊。如果緩存個人資訊，其他人很容易取得這些資訊。

不要緩存包含基于時間值的頁面，否則浏覽者将無法了解為何時間總是滞後。

不要緩存使用者随時都會修改的對象，如購物車。

ASP.net中常用的緩存方式有：

1）頁面緩存(對整個頁面進行緩存)

<%//Response.AddHeader("Last-Modified", DateTime.Now.AddHours(-1).ToString("r"));%>

<% Response.AddHeader("Cache-Control", "max-age=86400"); %>

<%//Response.AddHeader("Date", DateTime.Now.AddMinutes(-59).ToString("r"));%>

<%@Page OutputCache VaryByParams=”classid;page” Duration=”3600” %>

.net2.0中為：

<%@OutputCache VaryByParam=”classid;page” Duration=”3600” %>

你就可以有效的利用第一次請求裡生成的頁面輸出緩存内容，3600秒後重新生成一道頁面内容。這種技術其實也是運用一些低層的Cache API來實作。用頁面輸出緩存有幾個參數可以配置，如上面所說的VaryByParams參數，該參數表示什麼時候觸發重輸出的條件，也可以指定在 Http Get或Http Post 請求模式下緩存輸出。

例如當我們設定該參數為VaryByParams=”classid;page”的時候，default.aspx?classid=3&page=1 請求的輸出都會被緩存起來。沒有參數，或不用參數時用none。如果傳遞的參數不止一個，那麼即使字元串參數與值都相同，但排列次序不同，那麼在請求頁面時，也将生成不同的緩存頁。例如default.aspx?first=1&last=1 和default.aspx?last=1&first=1雖然參數完全相同，但由于排列次序不同，将生成兩個不同的緩存頁。

　　許多人都沒有意識到當用頁面輸出緩存的時候，asp.net也會生成HTTP頭集（HTTP Header）儲存在下遊的緩存伺服器中，這些資訊可以用于Microsoft Internet安全性中以及加速伺服器的響應速度。當HTTP緩存的頭被重置時，請求的内容會被緩在網絡資源中，當用戶端再次請求該内容時，就不會再從源伺服器上獲得内容了，而直接從緩存中獲得内容。

　　雖然用頁面輸出緩存不提高你的應用程式性能，但是它能減少了從的伺服器中加載已緩存頁面内容的次數。當然，這僅限于緩存匿名使用者可以通路的頁面。因為一旦頁面被緩存後，就不能再執行授權操作了。

2）片斷緩存(對頁面的某一部分,如某個User Control進行緩存)

<%@ OutputCache Duration="60" VaryByParam=”TextBox1;TextBox2” %>

在ASP.net中，除了在頁面範圍内使用緩存，也還可以針對User Control使用Output Cache參數實作對使用者控件的緩存。同樣的，一個頁面中相同類型的控件也可以有多個不同的緩存。可以根據參數來實作不同的緩存。頁面緩存和片斷緩存可以同時使用。

3）資料緩存

資料緩存是一種強大而又非常簡單的緩存機制，它可以在緩存區中為每個應用程式儲存各種對象，這些對象可以根據http的請求被調用，但是在各個不同的應用程式中這些對象都是私有的。

資料緩存是通過Cache類來實作的。當應用程式建立時，一個Cache類就同時被建立，緩存執行個體的生存周期就是應用程式的生存周期，它會随着應用程式的重新運作而重建，通過Cache類的方法，我們可以将資料對象放入緩存區，然後通過關鍵字比對尋找并使用這些對象。

Cache類通過一個借口來控制所有需要緩存的内容，包括規定緩存的時間和緩存方式，可以通過如下方法添加緩存對象：

Cache[“關鍵字”] = 關鍵字的取值；

然後通過下面的方法來通路這個對象：

string mKeyValue = “”;

if(Cache[“關鍵字”] != null)

{

mKeyValue = Cache[“關鍵字”];

}

注意Page.Cache和HttpContext.Current.Cache差別:

它們指的同一個對象，在Page裡，用Page.Cache，如果在global.asax或自己的類裡用:HttpContext.Current.Cache，在有些事件中，由于其沒有HttpContext，就用HttpRuntime.Cache。

資料緩存的過期依賴條件

某種意義上，Cache和Application是一樣的，都是一種公有的對象。為了取得緩存與資料有效性之間的平衡，可以根據需要對緩存過期政策進行合理的設定。

檔案依賴

Cache.Insert (“Mydata”, Source , New CacheDependency(Server.MapPath(“authors.xml”)));

此代碼的含義是當authors.xml檔案不發生變化的時候，緩存MyData始終有效。

時間依賴

設定1小時後過期，這是一種絕對過期。

Cache.Insert(“Mydata”,Source,null ,DateTime.Now.AddHours(1),TimeSpan.Zero);

相對過期依賴

當DataSet不再發生變化20分鐘以後，緩存過期。

Cache.Insert(“MyData”,Source,null,DateTime.MaxValue,TimeSpan.FromMinutes(20));

一個示例：

//絕對過期！！！(用來儲存公用的，資料量小的資料對象，可以是任何對象)

//設定

if (System.Web.HttpContext.Current.Cache["ok"] == null)

System.Web.HttpContext.Current.Cache.Insert("ok", "data", null, DateTime.Now.AddSeconds(300),System.Web.Caching.Cache.NoSlidingExpiration);

//讀取

if(System.Web.HttpContext.Current.Cache["ok"]!=null)

this.Response.Write(Convert.ToString(System.Web.HttpContext.Current.Cache.Get("ok")));

最後要注意：

在Web Form調試期間不能使用緩存，否則你對頁面所做的修改在緩存過期之前不會得到顯式加載。正确的做法應該是在調試結束之後，給需要放入緩存的頁面、使用者控件或對象加上緩存指令。最後建立部署和安裝項目，生成安裝資料包，這時候就可以到伺服器上去釋出你的産品了。

詳細參考：

http://hi.baidu.com/erics_lele/blog/item/674e46e7622f262cb83820c6.html

http://blog.csdn.net/chengking/archive/2005/10/03/494545.aspx

2、預請求緩存

　　雖然Cache API設計成用來儲存某段時間的資料，而預請求緩存隻是儲存某個時期的某個請求的内容。如果某個請求的通路頻率高，而且這個請求隻需要提取，應用，修改或者更新資料一次。那麼就可以預緩存該請求。我們舉個例子來說明。

　　在CS的論壇應用程式中，每一個頁面的伺服器控件都要求得到用于決定它的皮膚（skin）的自定義的資料，以決定用哪個樣式表及其它的一些個性化的東西。這裡面的某些資料可能要長時間的儲存，有些時間則不然，如控件的skin資料，它隻需要應用一次，而後就可以一直使用。

　　要實作預請求緩存，用Asp.net 的HttpContext類，HttpContext類的執行個體在每一個請求中建立，在請求期間的任何地方都可以通過HttpContext.Current屬性通路。HttpContext類有一個Items集合屬性，在請求期間所有的對象和資料都被添加到這個集合中緩存起來。和你用Cache緩存通路頻率高資料一樣，你可以用HttpContext.Items緩存那些每個請求都要用到的基礎資料。它背後的邏輯很簡單：我們向HttpContext.Items中添加一個資料，然後再從它裡面讀出資料。

五、配置web.config

1、一定要禁用調試模式

　　在部署生産應用程式或進行任何性能測量之前，始終記住禁用調試模式。如果啟用了調試模式，應用程式的性能可能受到非常大的影響。

<compilation defaultLanguage="c#" debug= "false" / >

2、必要時調整應用程式每個輔助程序的線程數

　　ASP.NET 的請求結構試圖在執行請求的線程數和可用資源之間達到一種平衡。已知一個使用足夠 CPU 功率的應用程式，該結構将根據可用于請求的 CPU 功率，來決定允許同時執行的請求數。這項技術稱作線程門控。但是在某些條件下，線程門控算法不是很有效。通過使用與ASP.NET Applications 性能對象關聯的 Pipeline Instance Count 性能計數器，可以在 PerfMon 中監視線程門控。

　　當頁面調用外部資源，如資料庫通路或 XML Web services 請求時，頁面請求通常停止并釋放 CPU。如果某個請求正在等待被處理，并且線程池中有一個線程是自由的，那麼這個正在等待的請求将開始被處理。遺憾的是，有時這可能導緻 Web 伺服器上存在大量同時處理的請求和許多正在等待的線程，而它們對伺服器性能有不利影響。通常，如果門控因子是外部資源的響應時間，則讓過多請求等待資源，對 Web 伺服器的吞吐量并無幫助。

　　為緩和這種情況，可以通過更改 Machine.config 配置檔案 <processModel> 節點的 maxWorkerThreads 和 maxIOThreads 屬性，手動設定程序中的線程數限制。

注意 輔助線程是用來處理 ASP.NET 請求的，而 IO 線程則是用于為來自檔案、資料庫或 XML Web services 的資料提供服務的。

配置設定給這些屬性的值是程序中每個 CPU 每類線程的最大數目。對于雙處理器計算機，最大數是設定值的兩倍。對于四處理器計算機，最大值是設定值的四倍。無論如何，對于有四個或八個 CPU 的計算機，最好更改預設值。對于有一個或兩個處理器的計算機，預設值就可以，但對于有更多處理器的計算機的性能，程序中有一百或兩百個線程則弊大于利。

　　注意 程序中有太多線程往往會降低伺服器的速度，因為額外的上下文交換導緻作業系統将 CPU 周期花在維護線程而不是處理請求上。

<httpRuntime maxRequestLength="4096"

useFullyQualifiedRedirectUrl="true" minFreeThreads="8" minLocalRequestFreeThreads="4"

appRequestQueueLimit="300"

executionTimeout="45"/>

Configuration setting 預設值 推薦值

-----------------------------------

maxconnection 2 12 * #CPUs

maxIoThreads 20 100

maxWorkerThreads 20 100

minWorkerThreads 50

minFreeThreads 8 88 * #CPUs

minLocalRequestFreeThreads 4 76 * #CPUs

appRequestQueueLimit 1000

3、仔細選擇會話狀态提供程式

　　ASP.NET 為存儲應用程式的會話資料提供了三種不同的方法：程序内會話狀态、作為 Windows 服務的程序外會話狀态和 SQL Server 資料庫中的程序外會話狀态。每種方法都有自己的優點，但程序内會話狀态是迄今為止速度最快的解決方案。如果隻在會話狀态中存儲少量易失資料，則建議您使用程序内提供程式。程序外解決方案主要用于跨多個處理器或多個計算機縮放應用程式，或者用于伺服器或程序重新啟動時不能丢失資料的情況。

<sessionState

mode= "InProc"

stateConnectionString= "tcpip=127.0.0.1:42424"

sqlConnectionString= "data source=127.0.0.1;Trusted_Connection=yes"

cookieless= "false"

timeout= "20"

/ >

4、 其他

　　根據适當的請求和響應編碼設定來配置應用程式。ASP.NET 預設編碼格式為 UTF-8。如果您的應用程式為嚴格的 ASCII，請配置應用程式使用 ASCII 以獲得稍許的性能提高。

　　 考慮對應用程式禁用 AutoEventWireup。在 Machine.config 檔案中将 AutoEventWireup 屬性設定為 false，意味着頁面不将方法名與事件進行比對和将兩者挂鈎（例如 Page_Load）。如果頁面開發人員要使用這些事件，需要在基類中重寫這些方法（例如，需要為頁面加載事件重寫 Page.OnLoad，而不是使用 Page_Load 方法）。如果禁用 AutoEventWireup，頁面将通過将事件連接配接留給頁面作者而不是自動執行它，獲得稍許的性能提升。

　　 從請求處理管線中移除不用的子產品。預設情況下，伺服器計算機的 Machine.config 檔案中 <httpModules> 節點的所有功能均保留為激活。根據應用程式所使用的功能，您可以從請求管線中移除不用的子產品以獲得稍許的性能提升。檢查每個子產品及其功能，并按您的需要自定義它。

例如，如果您在應用程式中不使用會話狀态和輸出緩存，則可以從 <httpModules> 清單中移除它們，以便請求在不執行其他有意義的處理時，不必執行每個子產品的進入和離開代碼。

六、其他

1、适當地使用公共語言運作庫的垃圾回收器和自動記憶體管理

　　小心不要給每個請求配置設定過多記憶體，因為這樣垃圾回收器将必須更頻繁地進行更多的工作。另外，不要讓不必要的指針指向對象，因為它們将使對象保持活動狀态，并且應盡量避免含 Finalize 方法的對象，因為它們在後面會導緻更多的工作。特别是在 Finalize 調用中永遠不要釋放資源，因為資源在被垃圾回收器回收之前可能一直消耗着記憶體。最後這個問題經常會對 Web 伺服器環境的性能造成毀滅性的打擊，因為在等待 Finalize 運作時，很容易耗盡某個特定的資源。

2、如果有大型 Web 應用程式，可考慮執行預批編譯

　　每當發生對目錄的第一次請求時都會執行批編譯。如果目錄中的頁面沒有被分析并編譯，此功能會成批分析并編譯目錄中的所有頁面，以便更好地利用磁盤和記憶體。如果這需要很長時間，則将快速分析并編譯單個頁面，以便請求能被處理。此功能帶給 ASP.NET 性能上的好處，因為它将許多頁面編譯為單個程式集。從已加載的程式集通路一頁比每頁加載新的程式集要快。

　　批編譯的缺點在于：如果伺服器接收到許多對尚未編譯的頁面的請求，那麼當 Web 伺服器分析并編譯它們時，性能可能較差。為解決這個問題，可以執行預批編譯。為此，隻需在應用程式激活之前向它請求一個頁面，無論哪頁均可。然後，當使用者首次通路您的站點時，頁面及其程式集将已被編譯。

　　沒有簡單的機制可以知道批編譯何時發生。需一直等到 CPU 空閑或者沒有更多的編譯器程序（例如 csc.exe（C# 編譯器）或 vbc.exe（Visual Basic 編譯器））啟動。

　　還應盡量避免更改應用程式的 /bin 目錄中的程式集。更改頁面會導緻重新分析和編譯該頁，而替換 /bin 目錄中的程式集則會導緻完全重新批編譯該目錄。

　　在包含許多頁面的大規模站點上，更好的辦法可能是根據計劃替換頁面或程式集的頻繁程度來設計不同的目錄結構。不常更改的頁面可以存儲在同一目錄中并在特定的時間進行預批編譯。經常更改的頁面應在它們自己的目錄中（每個目錄最多幾百頁）以便快速編譯。

　　Web 應用程式可以包含許多子目錄。批編譯發生在目錄級，而不是應用程式級。

3、使請求管線内的所有子產品盡可能高效

　　請求管線内的所有子產品在每次請求中都有機會被運作。是以，當請求進入和離開子產品時快速地觸發代碼至關重要，特别是在不使用子產品功能的代碼路徑裡。分别在使用及不使用子產品和配置檔案時執行吞吐量測試，對确定這些方法的執行速度非常有用。

4、避免單線程單元 (STA) COM 元件

　　預設情況下，ASP.NET 不允許任何 STA COM 元件在頁面内運作。若要運作它們，必須在 .aspx 檔案内将 ASPCompat=true 屬性包含在 @ Page 指令中。這樣就将執行用的線程池切換到 STA 線程池，而且使 HttpContext 和其他内置對象可用于 COM 對象。前者也是一種性能優化，因為它避免了将多線程單元 (MTA) 封送到 STA 線程的任何調用。

　　使用 STA COM 元件可能大大損害性能，應盡量避免。若必須使用 STA COM 元件，如在任何 interop 方案中，則應在執行期間進行大量調用并在每次調用期間發送盡可能多的資訊。另外，小心不要在構造頁面期間建立任何 STA COM 元件。例如下面的代碼中，在頁面構造時将執行個體化由某個線程建立的 MySTAComponent，而該線程并不是将運作頁面的 STA 線程。這可能對性能有不利影響，因為要構造頁面就必須完成 MTA 和 STA 線程之間的封送處理。

　　推薦的做法是在需要時或者在 Page_Load 方法中構造任何 COM 元件和外部資源。

　　永遠不要将任何 STA COM 元件存儲在可以由構造它的線程以外的其他線程通路的共享資源裡。這類資源包括像緩存和會話狀态這樣的資源。即使 STA 線程調用 STA COM 元件，也隻有構造此 STA COM 元件的線程能夠實際為該調用服務，而這要求封送處理對建立者線程的調用。此封送處理可能産生重大的性能損失和可伸縮性問題。在這種情況下，請研究一下使 COM 元件成為 MTA COM 元件的可能性，或者更好的辦法是遷移代碼以使對象成為托管對象。

5、将調用密集型的 COM 元件遷移到托管代碼

　　.NET Framework 提供了一個簡單的方法與傳統的 COM 元件進行互動。其優點是可以在保留現有投資的同時利用新的平台。但是在某些情況下，保留舊元件的性能開銷使得将元件遷移到托管代碼是值得的。每一情況都是不一樣的，決定是否需要遷移元件的最好方法是對 Web 站點運作性能測量。建議您研究一下如何将需要大量調用以進行互動的任何 COM 元件遷移到托管代碼。

　　許多情況下不可能将舊式元件遷移到托管代碼，特别是在最初遷移 Web 應用程式時。在這種情況下，最大的性能障礙之一是将資料從非托管環境封送到托管環境。是以，在互動操作中，請在任何一端執行盡可能多的任務，然後進行一個大調用而不是一系列小調用。例如，公共語言運作庫中的所有字元串都是 Unicode 的，是以應在調用托管代碼之前将元件中的所有字元串轉換成 Unicode 格式。

　　另外，一處理完任何 COM 對象或本機資源就釋放它們。這樣，其他請求就能夠使用它們，并且最大限度地減少了因稍後請求垃圾回收器釋放它們所引起的性能問題。

6、對于廣泛依賴外部資源的應用程式，請考慮在多處理器計算機上啟用網絡園藝

　　ASP.NET 程序模型幫助啟用多處理器計算機上的可縮放性，将工作分發給多個程序（每個 CPU 一個），并且每個程序都将處理器關系設定為其 CPU。此技術稱為網絡園藝。如果應用程式使用較慢的資料庫伺服器或調用具有外部依賴項的 COM 對象（這裡隻是提及兩種可能性），則為您的應用程式啟用網絡園藝是有益的。但是，在決定啟用網絡園藝之前，您應該測試應用程式在網絡園中的執行情況。

七、性能測試

在對ASP.NET應用程式進行性能測試之前，應確定應用程式沒有錯誤，而且功能正确。具體的性能測試可以采用以下工具進行：

1、Web Application Strees Tool (WAS)

　　Web Application Strees Tool (WAS)是Microsoft釋出的一個免費測試工具，可以從http://webtool.rte.microsoft.com/上下載下傳。它可以模拟成百上千個使用者同時對web應用程式進行通路請求，在伺服器上形成流量負載，進而達到測試的目的，可以生成平均TTFB、平均TTLB等性能彙總報告。

2、Application Center Test (ACT)

　　Application Center Test (ACT) 是一個測試工具，附帶于Visual Studio的企業版中，是Microsoft正式支援的web應用程式測試工具。它能夠直覺地生成圖表結果，功能比WAS多，但不具備多個客戶機同時測試的能力。

3、伺服器作業系統"管理工具"中的"性能"計數器，可以對伺服器進行監測以了解應用程式性能。