ASP.NET 應用程式的效能技巧

這兩天又碰到有人提出奇妙的 ASP.NET 效能問題（註1），查看之後，又興起了一個念頭，想把有關 ASP.NET 效能有關的東西稍微整理一下，以便日後發現其他與效能有關的東西時，有個地方可以集中存放。

這裡的效能秘訣有些是參考自 Improve Perfomance in ASP.net 這篇文章。文章裡面列了許多與提升效能有關的技巧，我只取個人覺得比較需要注意、對效能有顯著影響的項目。此外，我也加入了一點個人心得。

一般建議

• 把編譯選項的 debug 旗號關閉：
  
• 使用快取機制（網頁快取、資料／物件快取）。
• 盡量減少與 database server 或其他伺服器之間的通訊往返。
• 把 maxConcurrentRequestsPerCPU 加大至 5000（.NET 2.0 預設是 12，.NET 4 則為預設 5000）。此選項只對 integrated mode 有效，對以 classic mode 運行的應用程式沒有任何作用。延伸閱讀：Optimizing IIS Performance，ASP.NET Thread Usage on IIS 7.5, IIS 7.0, and IIS 6.0。
• 預先編譯網頁，並且關閉 AutoEventWireup。
• 在更新網站的 dll 組件或 App_Code 目錄中的類別時，使用 AppOffline.htm。也就是在更新網站時，放一個檔名叫做 AppOffline.htm 的網頁在應用程式的根目錄下。此網頁的內容是要顯示如「網站維護中、暫時停止服務」之類的訊息。更新完畢之後，再將此檔案刪除或改名即可。注意 AppOffline.htm 檔案至少要有 512 bytes。
• 盡量用 if 敘述來避免發生 expcetion（例外處理的成本比較貴）。
• 在大量使用多執行緒的情況（例如 AJAX），留意後端處理時是否有哪個地方會造成排隊（不要以為在前端或某個地方使用非同步的撰寫方式，程式就絕對跑得快）。
• 查看 application pool 選項，並了解各項設定的作用。有時候，某些效能問題可以透過調整 app pool 的選項來凸顯或消除其徵狀，這對於處理效能問題的初期研判階段具有縮小範圍的功用。

檢測與研判效能問題時，不要預設立場：這裡應該沒問題、那裡的寫法應該正確－－如果應該都沒問題，那程式也就「應該」沒有效能問題了。簡單講就是在不疑處有疑。

另外一個要點是不要看到影子就開槍，驟下結論。太快下結論，可能把自己導向錯誤的方向，白費許多工夫，也會讓旁人對你失去信心（先前說一定是這裡，然後說保證是那邊，現在又說 100% 是那個造成的 XD）。簡單講就是小心求證。

與 Session 有關的東西

• 存取 Session 時，ASP.NET 會自動處理 multiple threads 同時存取 Session 變數時的鎖定（lock）。這意味著若有兩個 request 要同時寫入 Session，其中一個必須排隊等候。你可以想像得到，如果你的網頁會發出大量的 AJAX 請求，而這些請求又與讀寫 Session 有關，就算 app server 有 32 核心，還是照樣會有排隊的情形。
• 若使用 out-of-process session，在存取 Session 資料時會比 in-process session 多花大約 15% 至 25% 的時間（註2）。使用 out-of-process session 時，必須考慮存入 Session 的物件能否序列化。

備註

註1：那是個 ASP.NET 2.0 應用程式，大量使用 AJAX。有個奇怪的現象是，同樣的 web service 和 dll 組件，如果部署到不同的網站（仍在同一台機器上），效能就會有很大的差異。這兩個網站的主要差別是，一個需要使用者登入，一個不需要。需要登入的網站，從網頁顯示的結果可以明顯看出，某些 AJAX 請求就是會等到特定請求完成之後才會接著完成。換言之，原本應該非同步進行的動作，到了後端卻變成排隊逐一處理了。

註2：參考自官方文件：Underpinnings of the Session State Implementation in ASP.NET（尋找字串 "15 percent"）