網站效能優化總結
在資料庫裡是預編譯的，也不需要在字串傳輸上花費大量時間。 防sql注入攻擊。
2. 儘量優化資料庫語句，使邏輯儘量簡單。 @ 還有就是在使用函式時 charindex >like > padindex 效率依次遞減。 @查詢欄位是否包含在以，分隔的欄位串時，最好不要用in 速度非常慢。 還有好多，可以總結的，這裡就不再描述了。
3. 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如果無安全上的特殊要求，保持預設值。
4. Pagelayout.頁面佈局模型。建議使用Flowlayout(元素不帶絕對定位屬性新增).Gridlayout(絕對定位屬性)由於採用絕對定位，將會比Flowlayout生產更多的程式碼，主要是控制元件的定位資訊。 radiobuttonlist 和 checkboxlist等
5. 專案釋出的時候切記解除頁面的Debug狀態
6. 儘量選擇html控制元件。能在客戶端實現的功能就在客戶端實現(熟練掌握javascript)，減少伺服器的壓力。資料控制元件選擇順序：Repeater、DataList、DataGrid
7. 在建立資料庫連線後只有在真正需要操作時才打開連線，使用完畢後馬上關閉，從而儘量減少資料庫連線開啟的時間，避免出現超出連線限制的情況
8. 字串操作效能優化
使用值型別的ToString方法
在連線字串時，經常使用"+"號直接將數字新增到字串中。這種方法雖然簡單，也可以得到正確結果，但是由於涉及到不同的資料型別，數字需要通過裝箱 操 。作轉化為引用型別才可以新增到字串中。但是裝箱操作對效能影響較大，因為在進行這類處理時，將在託管堆中分配一個新的物件，原有的值複製到新建立的物件中。使用值型別的ToString方法可以避免裝箱操作，從而提高應用程式效能。
運用StringBuilder類
String類物件是不可改變的，對於String物件的重新賦值在本質上是重新建立了一個String物件並將新值賦予該物件，其方法 ToString對效能的提高並非很顯著。在處理字串時，最好使用StringBuilder類，其.NET 名稱空間是System.Text。該類並非建立新的物件，而是通過Append，Remove，Insert等方法直接對字串進行操作，通過 ToString方法返回操作結果。
9.只要可能就快取資料或頁輸出
ASP.NET 提供了一些簡單的機制，它們會在不需要為每個頁請求動態計算頁輸出或資料時快取這些頁輸出或資料。另外，通過設計要進行快取的頁和資料請求(特別是在站點中預期將有較大通訊量的區域)，可以優化這些頁的效能。與 .NET Framework 的任何 Web 窗體功能相比，適當地使用快取可以更好的提高站點的效能，有時這種提高是超數量級的。使用 ASP.NET 快取機制有兩點需要注意。首先，不要快取太多項。快取每個項均有開銷，特別是在記憶體使用方面。不要快取容易重新計算和很少使用的項。其次，給快取的項分配的有效期不要太短。很快到期的項會導致快取中不必要的週轉，並且經常導致更多的程式碼清除和垃圾回收工作。若關心此問題，請監視與 ASP.NET Applications 效能物件關聯的 Cache Total Turnover Rate 效能計數器。高週轉率可能說明存在問題，特別是當項在到期前被移除時。這也稱作記憶體壓力。
10. 使用 HttpServerUtility.Transfer 方法在同一應用程式的頁面間重定向
採用 Server.Transfer 語法，在頁面中使用該方法可避免不必要的客戶端重定向。但要根據情況區分response.redirect .response.execute的使用方法。 區別對待。
11.適當地使用公共語言執行庫的垃圾回收器和自動記憶體管理
小心不要給每個請求分配過多記憶體，因為這樣垃圾回收器將必須更頻繁地進行更多的工作。另外，不要讓不必要的指標指向物件，因為它們將使物件保持活動狀態，並且應儘量避免含 Finalize 方法的物件，因為它們在後面會導致更多的工作。特別是在 Finalize 呼叫中永遠不要釋放資源，因為資源在被垃圾回收器回收之前可能一直消耗著記憶體。最後這個問題經常會對 Web 伺服器環境的效能造成毀滅性的打擊，因為在等待 Finalize 執行時，很容易耗盡某個特定的資源。
12.不要依賴程式碼中的異常
因為異常大大地降低效能，所以您不應該將它們用作控制正常程式流程的方式。如果有可能檢測到程式碼中可能導致異常的狀態，請執行這種操作。不要在處理該狀態之前捕獲異常本身。常見的方案包括：檢查 null，分配給將分析為數字值的 String 一個值，或在應用數學運算前檢查特定值。下面的示例演示可能導致異常的程式碼以及測試是否存在某種狀態的程式碼。
13.使用 HttpResponse.Write 方法進行字串串聯
該方法提供非常有效的緩衝和連線服務。但是，如果您正在執行廣泛的連線，請使用多個 Response.Write 呼叫。下面示例中顯示的技術比用對 Response.Write 方法的單個呼叫連線字串更快。
Response.Write(strString);
Response.Write("boxbig");
14.除非有特殊的原因要關閉緩衝，否則使其保持開啟
禁用 Web 窗體頁的緩衝會導致大量的效能開銷。 15.避免到伺服器的不必要的往返過程
使用 Page.IsPostBack 避免對往返過程執行不必要的處理
雖然您很可能希望儘量多地使用 Web 窗體頁框架的那些節省時間和程式碼的功能，但在某些情況下卻不宜使用 ASP.NET 伺服器控制元件和回發事件處理。通常，只有在檢索或儲存資料時，您才需要啟動到伺服器的往返過程。多數資料操作可在這些往返過程間的客戶端上進行。 16.ASP.NET應用程式效能測試
在對ASP.NET應用程式進行效能測試之前，應確保應用程式沒有錯誤，而且功能正確。具體的效能測試可以採用以下工具進行：Web Application Strees Tool (WAS)是Microsoft釋出的一個免費測試工具。它可以模擬成百上千個使用者同時對web應用程式進行訪問請求，在伺服器上形成流量負載，從而達到測試的目的，可以生成平均TTFB、平均TTLB等效能彙總報告。 Application Center Test (ACT) 是一個測試工具，附帶於Visual Studio.NET的企業版中，是Microsoft正式支援的web應用程式測試工具。它能夠直觀地生成圖表結果，功能比WAS多，但不具備多個客戶機同時測試的能力。伺服器作業系統"管理工具"中的"效能"計數器，可以對伺服器進行監測以瞭解應用程式效能。微軟還是出了IIS日誌檢視工具 LogParserLizardSetup.msi ,LogParser.msi 兩者配合使用。可檢視每一個頁面載入呼叫執行的時間。 17. 壓縮js，js在頁面中呼叫的大小寫要保持一致，免得快取了不同的檔案，頁面的js可以的話，寫成單位的檔案進行呼叫 。圖片少用jpeg，使用gzip 對網頁進行壓縮. 加快頁面展示速度。 18. 把呼叫js，儘量寫在頁面底部， 還有viewstate 狀態也可以重寫到頁面低部， 也可以把viewstate進行壓縮。條件是viewstate必要要用的情況之下。