ASP.NET效能最佳化

asp.net|效能|最佳化
衡量Web效能的方法



l         衡量web伺服器效能的唯一方式是對伺服器進行壓力測試（stress testing）



1.        自動壓力測試工具是衡量的唯一方式



2.        瀏覽器的點擊重新整理並不能作為痕量手段……




 


l         收集多個典型應用情境方案：



1.        在應用車工女婿執行過程中類比典型事物處理的過程



2.        痕量常用的單個頁面的效能（熱點）



3.        確定個情境及個頁面的使用率




 


l         通過測試找出系統的新能指標：



1.        伺服器的處理能力



2.        確定適合可接受TTFB/TTLB回應時間範圍的可支援的最大用戶端負載（並發使用者）




 



 


效能測試工具



l         微軟Web Application Stress Tool



1.        可免費下載（10MB），適用於XP、2000、2003



2.        http://www.microsoft.com/technet/treeview/default.aspx?url=/technet/itsolutions/intranet/downloads/webstres.asp




 


l         微軟應用程式中心測試載入器（Microsoft Application Center Test）



1.        作為VS.NET Enterprise 的一部分提供給客戶



2.        啟用更豐富的指令碼及報告




 



 


主要的效能測試觀測項PerfMon Counters



l         Processor，CPU % Utilization



Low numbers = blocking or lock contention




 


l         ASP.NET，Requests In Application Queue



出現線型增長時表示伺服器已達滿負荷




 


l         ASP.NET，Applications，Requests/Sec



動態輸送量（應保持一致、無大的波動）




 


l         ASP.NET，Applications，Errors Total



預示著功能級錯誤（應為0）




 


l         ASP.NET App/Worker Process Restarts



表示有嚴重錯誤編程級錯誤（應為0）



壓力測試環境的注意事項



l         在獨立與Web伺服器及應用伺服器的機器上運行壓力測試工具



1.        否則工具將超出伺服器CPU的最大範圍



2.        對於繁重的負載使用多個用戶端機器




 


l         對測試進行配置，以類比不同的用戶端頻寬層級



1.        特定用于衡量56K撥號




 


l         消除應用之外的任何瓶剄：



1.        網路、用戶端等




 



 


邏輯設計



l         建議：採用3層邏輯模型



1.        Pages and User Controls UI



2.        Business and Data Access classes in \bin dir



3.        Data withwin a SQL Database via SPROCs




 


l         設計系統時要考慮到Scale-Out的情形



1.        不要假設用戶端的請求




 


l         永遠會返回到同一機器




 



 


使用最佳的Data Provider



l         ADO.NET 可支援多個Provider:



1.        System.Data.SqlClient



2.        System.Data.OracleClient



3.        System.Data.OleDb



4.        System.Data.Odbc




 


l         所有Provider的編程模型相同



1.        但是效能方面存在明顯差異




 


l         建議：使用最佳



1.        在訪問MSDE/SQL 是始終使用SqlClient



2.        在訪問Oracle時始終使用OracleClient




 



 



 



 


DataReader vs.DataSets



l         DataReader



1.        對查詢的結果提供了單向讀取的操作



2.        輕量快速-但在Reader關閉之前資料庫始終處於串連狀態




 


l         DataSet



1.        非串連的資料訪問方式



2.        內部使用DataReader使用者擷取資料



3.        在完成DataSet的擷取後會自動關閉DataReader




 


l         Which is better?



1.        依賴於你的應用



2.        原則上在Middle_Tier設計到大量資料處理或進行離線的資料訪問時建議使用DataSet




 



 


串連池



l         ADO.NET擁有內建的串連遲



1.        自動緩寸/重新使用串連



2.        不必為此編寫任何代碼




 


l         代碼建議



1.        “在後期開啟代碼中的串連，然後在早期將其關閉”



2.        切無長時間保持串連狀態 – 切無嘗試構建你自己的“智能”串連池邏輯



3.        完成後應立即顯示地關閉資料庫連接，以將其返回致池中




 


l         最佳化提示：



1.        不同的連接字串可以產生多個不同的串連池



2.        在Web.Config中儲存單個連接字串



3.        使用ConfigurationSettings.AppSettings以在運行時採用編程形式對其進行訪問



4.        觀察”.NET CLR資料“效能計數器，以變對由ADP.NET維護的串連池數量保持




 



 


使用預存程序



l         建議將SPROC用於資料存取



1.        通過DBA進行更輕鬆的效能調試



2.        通過使用資料庫交易處理避免出現分布事務成本



3.        有助於防止SQL注入攻擊



4.        有助與消除應用與資料庫反覆調用的成本




 



 



 


伺服器控制項



l         對效能最佳化而言有兩點需要注意:



1.        ViewState



2.        Number of controls generated(especially for lists)




 



 


ViewState管理



l         ASP.NET controls能夠維護頁面Control元素的狀態:



1.        狀態以”viewstate” hidden field進行傳遞




 


l         負面影響:



1.        增加網路負荷（both on render and postback）



2.        額外的伺服器效能消耗（serialize values to/from viewstate）




 


l         ViewState靈活性:



1.        頁面級（Can disable viewstate entirely for a page）



2.        控制項級（Can disable viewstate usage on a per control basis）




 


l         建議



1.        認真審核該功能的使用



2.        若不使用PostBack功能，在頁面級屏蔽ViewState



3.        PostBack時沒次都重建控制項，請對控制項級的ViewState屏蔽



4.        使用<%@ Page Trace=”true”%>跟蹤ViewState的大小