如何提高ASP.NET性能
如果您在ASP.NET中編寫的代碼，那么你需要通過以下幾點，以確保良好的性能：
◆ 你是否使用緩存嗎?
◆ 你是否使用會話狀態?
◆ 你使用的應用程序狀態嗎?
◆ 你使用線程和同步功能?
◆ 你資源的有效管理呢?
◆ 你有效地管理字符串?
◆ 你有效地管理例外?
◆ 有你優化你的網頁?
◆ 你使用視圖狀態?
◆ 你使用服務器控件嗎?
◆ 你從你的頁面訪問數據嗎?
◆ 你可以使用數據綁定嗎?
◆ 你從ASPX頁面調用非托管代碼?
◆ 你有沒有審查Machine.config中的設置嗎?
您使用緩存嗎?
使用下面的復習題，以評估您的代碼使用ASP.NET緩存功能：
◆ 你有太多的變化輸出緩存嗎?
檢查您的網頁，使用輸出緩存，以確保數量變化有限制。輸出緩存頁面太多的變化可以導致內存使用量的增加。您可以識別的網頁，使用搜索字符串“OutputCache”輸出緩存。
◆ 你能使用輸出緩存?
在審查您的網頁時，開始問自己：如果可以緩存整個頁面 。如果整個頁面不能被緩存，可以把它的部分被緩存?即使數據不是一成不變的，可以考慮使用輸出緩存 。如果您的內容并不需要在近實時傳送，考慮輸出緩存。
使用輸出緩存緩存，無論是整個頁面或部分頁面可以顯著提高性能 。
◆ 有，將更好地存儲在緩存中的靜態數據?
識別應用程序端的數據是靜態的還是很少更新。這種類型的數據存儲在緩存中的一個偉大的候選人。
◆ 你訪問緩存中的項目為空值之前檢查嗎?
前檢查null訪問緩存的項目，如下面的代碼片段所示，您可以提高性能。
- Object item = Cache["myitem"];
- if (item==null)
- {
- // repopulate the cache
- }
這有助于避免任何導致的異常空對象。為了找到你的代碼在您訪問緩存。
您使用會話狀態?
使用下面的復習題，審查代碼的使用會話狀態：
◆ 你不需要時禁用會話狀態?
默認情況下，會話狀態仍然。如果您的應用程序不使用會話狀態，禁用它在Web.config文件如下：
如果您的應用程序的某些部分需要會話狀態，確定不使用它，這些頁面禁用它通過使用下面的頁面級別屬性的頁面。
◆ 最大限度地減少使用的會話狀態，增加了應用程序的性能。
◆ 你有頁面不寫一個會話嗎?
使用會話狀態的頁面請求在內部使用ReaderWriterLock，管理會話狀態的訪問。對于只讀會話數據的網頁，，考慮的EnableSessionState設置為ReadOnly。
- <%@ Page EnableSessionState="ReadOnly" . . .%>
這是特別有用，當您使用HTML框架。默認設置(由于ReaderWriterLock)頁面執行序列化。將它設置為只讀，可以防止阻塞和允許更多的并行。
◆ 你檢查之前在會話狀態的訪問中的項目為空值?
為空，然后再訪問該項目的檢查，在下面的代碼所示，您可以提高性能。
- object item = Session["myitem"];
- if(item==null)
- {
- // do something else
- }
常見的錯誤，從會話狀態中檢索數據時是不檢查，如果數據是空的，前訪問，然后捕獲由此導致的異常。你應該避免這種情況，因為異常是昂貴的。要找到你的代碼訪問會話狀態，你可以搜索字符串“會議”。
◆ 你復雜的對象存儲在會話狀態嗎?
避免復雜的對象存儲在會話狀態，特別是如果你使用一個徹頭徹尾的進程外會話狀態存儲。當使用進程外會話狀態，對象被序列化和反序列化的每個請求，從而降低性能。
◆ 你STA COM對象存儲在會話狀態嗎?
存儲在會話狀態中的單線程單元(STA)COM對象會導致線程關聯，因為會話綁定到原來的線程上創建該組件。這嚴重影響性能和可擴展性。確保您使用以下頁面級別屬性在任何網頁上，STA COM對象存儲在會話狀態。
這力量運行頁面的STA線程池，避免任何昂貴的公寓開關從默認的多線程單元(MTA)為ASP.NET線程池。在可能的情況下，避免使用STA COM對象。
你使用應用程序狀態嗎?
使用下面的復習題，如何有效地評估你的代碼使用應用程序狀態：
◆ 你STA COM組件存儲在應用程序的狀態?
避免STA COM組件存儲在應用程序的狀態在可能的情況下。這樣做有效地瓶頸您的應用程序到一個單獨的執行線程訪問組件時。在可能的情況下，應避免使用STA COM對象。
◆ 你使用的應用程序狀態字典嗎?
用于存儲只讀的值可以設置在應用程序初始化時，不改變之后，你應該使用的應用程序的狀態字典。要知道在代碼中使用時，應用程序的狀態，如以下幾個問題：
分配到應用程序變量的存儲的內存沒有被釋放，除非它們被取出或更換。
應用程序狀態不是Web場或Web園 - 共享存儲在應用程序狀態中的變量是全球性的的特定應用程序運行過程中，。每個應用程序進程可以有不同的價值觀。
◆ 考慮使用以下替代應用程序的狀態：
為應用程序而不是使用狀態字典創建的靜態屬性。它是更有效的訪問狀態字典查找比一個靜態屬性。例如，考慮下面的代碼：
這是更有效地使用下面的代碼：
使用配置文件，用于存儲應用程序的配置信息。
考慮緩存數據是足夠的揮發性，它不能存儲在應用程序的狀態，但需要定期更新緩存中的對象，從一個持久化介質。
使用會話存儲用戶特定的信息。你可以找出你的代碼的地方使用搜索字符串“應用”應用程序的狀態。
你使用應用程序狀態嗎?
NET Framework公開各種線程和同步功能，您的代碼中使用多線程的方式可以有一個應用程序的性能和可擴展性的顯著影響。使用下面的復習題，到如何有效地評估你的ASP.NET代碼使用線程：
◆ 你創建線程每個請求的基礎上?
避免手動創建ASP.NET應用程序中的線程。創建線程是一項昂貴的的操作，需要初始化托管和非托管的資源。如果你需要額外的線程來執行工作，使用CLR線程池。為了找到你的代碼的地方，你正在創建線程，搜索字符串“的ThreadStart”。
◆ 你執行長時間運行的阻塞操作嗎?
避免堵在你的ASP.NET應用程序在可能的情況下操作。如果你必須執行一個長時間運行的任務，然后再考慮使用異步執行(如果你可以自由調用線程)或使用異步“火，忘記”模型。
資源的有效管理呢?
使用以下的檢討，以評估您的代碼如何有效地使用資源的問題：
你明確地關閉資源?
確保您的代碼明確關閉對象實現IDisposable接口通過調用對象的Dispose或Close方法。未能關閉資源和迅速，可導致內存消耗增加，表現不佳。
沒有關閉數據庫連接，是一個普遍問題。使用finally塊(或在C#中使用的塊)來釋放這些資源，以確保資源被關閉，即使發生異常。
池共享資源呢?
檢查您使用池訪問共享資源時，以提高性能。確保共享資源，如數據庫連接和服務組件，可以匯集，正在匯集。沒有集中，你的代碼即被初始化的開銷每個共享資源的使用時間。
你晚獲取資源和早期釋放他們?
打開共享資源之前，你需要他們，只要你完成他們釋放。持有時間比你需要的人士，到資源，增加內存的壓力，并增加對這些資源的競爭，如果他們共享。
你塊數據傳輸I / O調用嗎?
如果你需要在塊I / O調用的數據傳輸，分配和針塊用于發送和接收緩沖區。如果您需要進行并發的I / O調用，你應該創建一個固定的回收這是在不同的客戶，而不是每個請求的基礎上創建一個緩沖區的緩沖區池。這可以幫助您避免堆碎片和減少緩沖區的創建時間。
您有效地管理弦樂?
使用下面的復習題，以評估如何有效地你的ASP.NET代碼操縱字符串：
你使用的格式化輸出的Response.Write嗎?
確定你的代碼在您連接輸出，如創建一個表，并考慮使用Response.Write來代替。回復于書面內容給客戶端的最有效的方法。
你使用StringBuilder來連接字符串嗎?
如果追加數量是未知的，你不能發送數據到客戶端使用的Response.Write立即的，使用StringBuilder類來連接字符串。
你=連接字符串+嗎?
確定在你的代碼的地方，你使用+ =運算符執行字符串串聯。如果追加的數量是未知的，或你追加一個未知大小的數據，考慮使用StringBuilder類來代替。
您有效地管理例外?
使用以下審查問題，如何有效地評估您的代碼中使用異常：
有你在Global.asax中實現了一個錯誤處理程序?
雖然落實在Global.asax中的錯誤處理程序不一定提高性能，它可以幫助您確定您的應用程序，在發生意外異常。您找出發生的異常后，采取適當的行動，以避免這些例外。
你使用的try /可支配資源終于?
確保在finally塊中釋放，以確保他們得到清除，即使在異常事件，可支配資源。不處置的資源，是一個普遍問題。
請問你的代碼，避免異常?
你的代碼應該試圖避免例外，以提高性能，因為異常會導致顯著的開銷。使用以下方法：
檢查空值。
不要使用異常來控制常規應用程序邏輯。
不要捕獲異常，你不能處理和模糊有用的診斷信息。
使用重載Server.Transfer方法Server.Transfer的(字符串，BOOL)，而不是Server.Transfer的，Response.Redirect，Response.End，以避免異常。
您優化您的網頁?
使用下面的復習題，評估aspx頁的效率。
你采取的步驟，以減少頁面大小?
盡量保持頁面大小到最低限度。較大的頁大小，因為增加的處理能力和網絡帶寬利用率，從而可能導致網絡擁塞的顯著增加CPU的負載增加。這兩個因素導致響應時間增加為客戶。考慮以下的指引，以協助減少頁面大小：
包括使用腳本(腳本，而不是點綴的HTML代碼標簽)。
從你的HTML中刪除多余的空白字符。
禁用它不需要服務器控件的視圖狀態。
避免長時間的控制名稱。
最小化使用的圖形，并使用壓縮圖像。
考慮使用級聯樣式表，以避免反復相同的格式指令發送到客戶端。
緩沖禁用?
確保你有緩沖啟用。緩沖會導致服務器緩沖輸出和發送后，才完成了處理頁面。如果緩沖被禁止，勞動者的過程，需要不斷流從所有的并發請求的響應，這可能是內存和處理器上的顯著的開銷，尤其是當你使用ASP.NET進程模型。要找出緩沖禁用，如果你有，你可以搜索以下字符串為您的代碼庫：“緩沖區”和“BufferOutput。”確保緩沖區<pages>元素屬性設置為true，在您的應用程序的Web.config 文件。
- <pages buffer="True">
#p#
你使用Response.Redirect嗎?
搜索你的代碼為“Response.Redirect”，并考慮更換與Server.Transfer的。這并不招致了一個新的請求成本，因為它避免了任何客戶端重定向。
你不能總是簡單地取代Response.Redirect調用Server.Transfer的調用，因為Server.Transfer使用一個新的處理程序在執行的處理程序階段。Response.Redirect產生第二個請求。如果你需要不同的身份驗證和授權，緩存，或其他運行時設備上的目標，這兩個機制是不等價的。Response.Redirect導致一個額外的請求被發送到服務器。Response.Redirect也使得用戶可見的網址。這可能需要在某些情況下，您要求用戶書簽的新位置。
你使用Page.IsPostBack?
檢查在你的頁面的邏輯使用Page.IsPostBack屬性，以減少多余的處理，避免不必要的初始化成本。使用Page.IsPostBack屬性有條件地執行代碼，根據頁面是否是響應服務器控件事件生成，或者它是否是首次加載。
你驗證用戶輸入?
檢查，驗證用戶輸入客戶端上，以減少服務器的往返行程。這也提供了更好的反饋給用戶。出于安全原因，確保任何客戶端驗證與對應的服務器端驗證贊揚。
你有沒有制定明確和嚴格的真實?
確保您使用Option Strict和明確，以減少意外的后期綁定，當使用Visual Basic。NET中。
- <%@ Page Language="VB" Explicit="true" Strict="true" %>
這可以很容易地搜索，使用正則表達式的Findstr.exe進行文件。
- C:\findstr /i /s /r /c:"<%.*@.*page.*%>" *.aspx
- pag\default.aspx:<%@ Page Language="VB" %>
- pag\login.aspx:<%@ page Language="VB" %>
- pag\main.aspx:<%@ Page Language="VB" Explicit="true" Strict="true" %>
- ...
您已禁用調試?
檢查你的Web.config文件，并確保調試設置為false 節和檢查。aspx頁，以確保調試設置為false。如果啟用了調試，編譯器不生成優化的代碼和頁面批次編譯。您可以通過使用正則表達式的Findstr.exe進行文件。aspx頁。
- C:\pag>findstr /i /r /c:"<%.*@.*page.*debug=.*true*.*%>" *.aspx
- login.aspx:<%@ page Language="VB" Debug="True" %>
- main.aspx:<%@ Page Language="c#" Debug="True" %>
您已禁用跟蹤?
檢查您的Web.config文件，以確保在部分禁用跟蹤。另外，請檢查你的。aspx頁，以確保跟蹤設置為false。您可以通過使用正則表達式的Findstr.exe進行文件。aspx頁。
- C:\pag>findstr /i /r /c:"<%.*@.*page.*trace=.*true*.*%>" *.aspx
- login.aspx:<%@ page Language="VB" Trace="True" %>
- main.aspx:<%@ Page Language="c#" Trace="True" %>
你積極的超時嗎?
設置超時積極相應調整。評估每一頁，并確定一個合理的超時。默認頁是在Machine.config執行超時屬性指定超時90秒。服務器資源舉行，直到請求被處理完全或執行時間，以較早者為準。在大多數情況下，用戶不必等待這樣一個長時間才能完成的請求。他們要么完全放棄請求，或發送一個新的請求，這進一步增加了服務器上的負載。
您使用視圖狀態?
使用下面的復習題，以評估您的應用程序如何有效地使用視圖狀態：
你禁用視圖狀態時，它不需要?
每一頁的評估，以確定是否需要查看狀態啟用。視圖狀態會增加開銷每個請求。開銷包括增加頁面發送到客戶端，以及一個序列化和反序列化成本的大小。你不需要查看在下列條件下的狀態：
頁面不回自己的頁面僅用于輸出和不依賴于響應處理。
你的頁面的服務器控件不處理事件，你有沒有動態的或數據綁定的屬性值(或他們是在每個請求的代碼)。
如果你忽略的舊數據，并重新填充的服務器控制每次刷新頁面。
您已經采取步驟，以減少您的視圖狀態的大小嗎?
評估每一頁的視圖狀態的使用。要確定一個頁面的視圖狀態的大小，您可以啟用跟蹤，看看每個每個控制如何使用它。控制控制的基礎上，禁用視圖狀態。
你使用服務器控件嗎?
使用下面的復習題，檢討如何有效地你的ASP.NET應用程序使用服務器控件：
你使用服務器控件時，你不需要嗎?
評估您的服務器控件的使用，以確定是否可以替換他們具有重量輕HTML控件或可能是靜態的文本。你也許可以在下列情況下更換一個服務器控件：
在控制顯示的數據是靜態的，例如，一個標簽。
你并不需要以編程方式訪問在服務器端控制。
控制顯示的是只讀數據。
在回處理過程中不需要控制。
你有服務器控制的深層次嗎?
服務器控件嵌套很深的層次復合的建設控制樹成本。考慮呈現的內容自己使用Response.Write或建立一個自定義的控制，并呈現。要確定的控制和控制層次，使頁面的跟蹤。
您從您的ASPX頁面訪問數據嗎?
大多數ASP.NET應用程序需要某種形式的數據訪問。數據訪問的性能和可擴展性問題發現一個共同的地方。審查以下問題，以幫助改善您的應用程序的頁面級別的數據訪問：
你頁大的結果集?
確定您的應用程序領域，大的結果集顯示和考慮分頁的結果。大的結果集顯示給用戶，可以對性能有顯著影響。
你使用數據集時，你可以使用DataReaders嗎?
如果你不需要緩存數據，層與層之間或數據的交換數據綁定到一個控制和只需要只進，只讀訪問數據，然后使用DataReader，而不是。
您可以使用數據綁定嗎?
使用下面的復習題，審查代碼的數據綁定使用：
你用的Page.DataBind嗎?
避免調用的Page.DataBind和單獨的每個控件綁定優化您的數據綁定。調用的Page.DataBind遞歸調用上的每個頁面上的控件的DataBind。
你使用的DataBinder.Eval嗎?
DataBinder.Eval的使用反射，從而影響性能。在大多數情況下，DataBinder.Eval的被稱為從一個頁面內多次，因此，實施替代方法提供了一個很好的機會，以提高性能。
避免以下做法：
- <itemtemplate>
- <table><tbody><tr>
- <td><%# DataBinder.Eval(Container.DataItem,"field1") %></td>
- <td><%# DataBinder.Eval(Container.DataItem,"field2") %></td>
- </tr></tbody></table>
- </itemtemplate>
使用顯式轉換。它提供了更好的性能，避免反射的成本。投作為一個DataRowView Container.DataItem，如果數據源是DataSet。
- <itemtemplate>
- <table><tbody><tr>
- <td><%# ((DataRowView)Container.DataItem)["field1"] %></td>
- <td><%# ((DataRowView)Container.DataItem)["field2"] %></td>
- </tr></tbody></table>
- </itemtemplate>
投作為一個String Container.DataItem如果數據源是一個數組或一個ArrayList。
- <itemtemplate>
- <table><tbody><tr>
- <td><%# ((String)Container.DataItem)["field1"] %></td>
- <td><%# ((String)Container.DataItem)["field2"] %></td>
- </tr></tbody></table>
- </itemtemplate>
aspx頁面調用非托管代碼嗎?
使用下面的復習題，審查代碼的互操作性使用：
你有沒有啟用調用STA COM組件ASPCOMPAT嗎?
確保任何頁面調用STA COM組件ASPCOMPAT頁面級別屬性設置。這將指示ASP.NET使用STA線程池線程來執行當前頁面的請求。默認情況下，ASP.NET使用MTA線程池來處理頁面請求。如果您正在使用STA元件，組件綁定到創建的線程。這將導致一個從線程池中的線程STA對象是創建的線程昂貴的線程切換。
你創建STA COM組件在頁面的構造?
檢查您的網頁，以確保您沒有創建STA COM組件在頁面的構造。創建STA組件中的Page_Load，Page_Init或其他事件，而不是。頁面的構造函數總是一個MTA線程上執行。當STA COM組件是從一個MTA線程創建，創建STA COM組件在主機上的STA線程。在同一個線程(主機STA)執行單元線程組件從MTA線程創建的所有實例。這意味著，即使所有的用戶都有他們自己的COM組件實例的引用，所有到這些組件的調用序列化這一個線程，并在同一時間只有一個呼叫執行。這將有效地瓶頸一個單獨的線程的頁面，并造成重大的性能下降。如果您使用的是AspCompat屬性，這些事件運行一個線程使用STA線程池，它在一個較小的性能結果擊中由于線程切換。
你用Server.Create對象嗎?
避免使用Server.CreateObject和早期綁定到您的組件在編譯時盡可能。Server.CreateObject的使用后期綁定，主要是為了向后兼容提供。搜索您的代碼庫，看看是否使用這個例程，作為替代，創建互操作程序集，利用早期綁定的優勢。
你有沒有審查Machine.config中的設置嗎?
使用下面的復習題，審查您的應用程序的部署計劃：
調整適當的線程池?
CLR線程池調整適當的調整，提高了性能顯著。在部署應用程序之前，確保該線程池已調整為您的應用程序。
適當配置的內存限制?
配置ASP.NET內存限制，確保最佳的ASP.NET緩存的性能和服務器的穩定性。在IIS 5.0中，或者當您使用在IIS 6.0的ASP.NET進程模型，配置Machine.config中的內存限制。在IIS 6.0中，您使用IIS MMC管理單元中配置的內存限制。
你刪除不必要的HttpModules?
包括的HttpModules，你不需要添加額外的開銷ASP.NET請求處理。檢查您已刪除或注釋掉在未使用的HttpModules 的Machine.config。
原文：http://www.cnblogs.com/caltion/archive/2011/10/12/2208283.html
【編輯推薦】
