你使用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。