Web應用程序性能調優
1.1 背景介紹
性能考慮必須貫穿在日常的編碼中，性能監控要列入QA日常工作，每個程序員都要懂得如何做性能調優。性能往往與程序性能、數據量、瀏覽器性能負載、服務器負載、網絡帶寬
等都有關系。
1.2 技術知識點
1.2.1 相關工具
程序性能是否存在問題，必須以實際的監控數據作為參考，包括請求開始時間、持續時長、頁面大小、數據量等等。這里介紹幾種常用的監控工具。
1.2.1.1 Firebug
Firefox插件，版本V1.2.1，提供對HTML、CSS、腳本、Dom、網絡、Cookie等的監控。性能調優主要利用網絡選項，監控請求執行的時間；必要時也可以監控HTML、腳本和Cookie。
適用于Firefox環境，監控單次請求頁面和單詞的Http Web請求，免費。 https://addons.mozilla.org/zh-CN/firefox/addon/1843
1.2.1.2 Http Watch
IE、Firefox插件，版本V6.0.17。V5.x版本只適用于IE。提供對單個Http Web請求的監控，包括其Header、Cookie、Cache、Content等等，其Time Chart提供對發送、等待、接收
三個階段時長的精確監控。收費，有破解。 http://www.httpwatch.com/
1.2.1.3 Fiddler2
獨立程序，版本V2.1.9.4 Beta，提供對所有IE發出的Http Web請求的監控，包括Header、Content、Time Line、Catch等。適用于需要對Http Web請求和響應內容的詳細監控。免
費，基于.NET構建，需要安裝.NET Framework。http://www.fiddler2.com/fiddler2/
1.2.1.4 Pingdom
免費的整站測試工具，其模擬瀏覽器載入指定頁面的所有資源，包括HTM;、CSS、Javascript等所有對象，并在時間軸面板上顯示每個對象載入的具體時間。如下圖所示。
http://tools.pingdom.com
1.2.1.5 MSSQL Server Profile
MSSQL Server 2005的組成部分，對數據庫性能進行監控。通常用于監控是否多次執行特定存儲過程，以及特定存儲過程執行的時長。這里不贅述。
1.2.1.6 VS Studio Trace
VS Studio Debug工具的一部分，用于在程序中輸出相應的調試信息，由此監控特定方法執行的時長；允許在web.config中控制是否輸出調試信息。通常搭配trace.axd監控POST請
求。適用于單個頁面對每個方法執行時長的監控。
應用程序級別的Trace
<configuration>
<system.web>
<trace enabled="true" requestLimit="40" localOnly="false" pageOutput ="false"/>
</system.web>
</configuration>
單個頁面的Trace
請在該頁的 @ Page 指令中將 Trace 屬性設置為 false。將存儲您包括在頁代碼中的任何 TraceContext.Write 或 TraceContext.Warn 語句，并且它們只返回到跟蹤查看器。
如果希望跟蹤信息附加到與其關聯的頁的末尾，請在 Web.config 文件的跟蹤配置節中將 pageOutput 屬性設置為 true。如果要跟蹤信息只顯示在跟蹤查看器中，則將該屬性設置
為 false。如果您啟用應用程序級跟蹤，但不想顯示應用程序某些頁的跟蹤信息，則使用 @ Page 指令將不想顯示 跟蹤信息的頁的 Trace 屬性設置為 false。
通過http://localhost/trace.axd 查看Get和Post的跟蹤信息。
1.2.2 調優方向
1.2.2.1 單個請求或方法執行時間特別長
問題描述
由于代碼、數據量、存儲過程等原因，導致某個請求或者方法執行時間特別長，導致性能瓶頸。比如Order Complete頁面（DDN-622，DDN-624），通過UPS實時獲取Delivery Date
耗時需要1秒。
如何調優
查看頁面代碼、特定方法是否有優化的可能性。利用Http Watch監控每個HTTP Web請求，對于在內網執行時間超過100毫秒（頁面大小100K以內）特別留意。必要時利用Trace監控
相應頁面方法的執行時長，比如Page_Load、相關響應事件等。
1.2.2.2 頁面數據量特別大
問題描述
由于頁面數據量特別大，在數據量獲取（Server一級）、瀏覽器呈現可能會導致性能。通過Http Watch監控發送、等待、接收的時長。判定是否違反“只取所需”的原則導致數據
冗余。比如，Order Complete頁面加載需要600毫秒以上（DDN-613），由于加載Order信息時將Shipping Info、Payment Info也一并加載進來，造成在數據庫級別的數據冗余和時
間浪費。
如何調優
只取所需，減少數據冗余。
1.2.2.3 頁面特別大
問題描述
由于所需呈現的數據量特別大，造成HTML頁面特別大，瀏覽器解析呈現緩慢，造成性能瓶頸。比如Bom的Component Usage、Insertion & Guarantee ，由于矩陣數據造成頁面容量
超過2M、4M。
如何調優
使用更加緊湊的HTML，減少HTML嵌套，不再使用.NET默認的校驗器，減少頁面容量；限制不必要的ViewStage。
1.2.2.4 Javascript性能瓶頸
問題描述
瀏覽器對Javascript的執行性能差異造成此瓶頸，特別是當頁面比較大的時候，IE的執行效率只有Firefox、 Safari的60%左右。比如document.getElementById()可能造成性能瓶
頸。
如何調優
用JQuery的API替代普通的Javascirpt API，在Javascript一級緩存數組。
1.2.2.5 存儲過程性能瓶頸
問題描述
數據庫一級未做優化，比如主鍵、索引，導致查詢效率低下；存儲過程使用了效率低下的語句，比如IN查詢、臨時表、實時統計、動態查詢、游標循環等，造成執行效率低下。
如何調優
建立主鍵、索引，使用效率更高的執行語句；用統計表替代實時統計。參照：080319DatabaseCapability的培訓記錄。當數據量比較小的時候，通過定義表變量而不是臨時表處理
。
1.2.2.6 減少HTTP請求次數
問題描述
在Javascript循環中通過Ajax多次發起HTTP請求；頁面中內嵌多個IFRAME；頁面頻繁刷新或者重載。
如何調優
不在循環中發起HTTP請求；適當的數據和頁面緩存；減少內嵌IFRAME的使用。避免頁面頻繁刷新。
1.2.2.7 避免多次調用數據庫
問題描述
在方法循環中多次調用業務類訪問數據庫，比如For each、Data Bind、Date Item Bound。MSSSQL Server Profile能監控到此類操作。
如何調優
避免多次調用數據庫，如確實需要查詢，在數據量少的情況下，將數據緩存在內存并在緩存中查詢。
1.2.3 調優步驟
? 結合Http Watch、Firebug確認每個頁面請求的執行時長，憑經驗判定是否存在性能瓶頸。
? 在頁面適當位置添加trace信息，確認哪些方法比較費時。
? 代碼審查，查找存在問題的代碼、存儲過程、腳本。
? 確認每次查詢的數據量和預期結果，過濾冗余數據。
? 調優后，程序性能須有數量級上的改善。
1.2.4 代碼規范
? 嚴格執行公司的代碼規范，特別是命名、存儲過程規范。
? 每次代碼提交之前，利用SVN DIFF工具確認每個代碼修改，確認無誤后再提交。
? 每一個分出去的Issue，導師、PM、Team Leader必須做到代碼審查。
? 不重復制造輪子，注意代碼封裝和復用，不制造冗余代碼。
? 對Cookie、Session集中管理，KEY要管理起來；不再使用的代碼、方法要及時刪除。
1.3 項目實踐
1.3.1 監控每個頁面的執行時長
利用Firebug、Http Watch、Filddler2、Pingdom分別監控可疑頁面的執行時長，判斷可能導致頁面性能低下的代碼塊。
1.3.2 監控Profile
對可疑代碼進行代碼審查，如果懷疑是由于存儲過程等原因導致的數據庫性能低下，結合MSSQL Server Profile監控可疑存儲過程或者表結構。
1.3.3 Trace監控方法執行的時長
對可疑代碼進行代碼審查，如果懷疑是由于C#代碼導致的頁面性能低下，結合VS Studio Trace監控代碼段的執行時長。
1.4 參考資料
《高性能網站建設指南》
http://www.cnblogs.com/JeffreyZhao/category/82418.html
http://www.cnblogs.com/FrameWork/archive/2006/10/16/529835.html
http://www.cnblogs.com/FrameWork/archive/2006/10/16/530827.html
1.5 學習建議
養成良好的編碼習慣
避免常見的編碼誤區
柳德才
13691193654
18942949207
QQ：422157370
liudecai_zan@126.com湖北-武漢-江夏-廟山