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 PerformanceASP.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")

沒有留言:

技術提供:Blogger.
回頂端⬆️