在用ASPNET開發網站的時候性能是永遠需要考慮和關注的問題性能不僅僅只是程序代碼執行時候的速度而是涉及到方方面面的東西
就拿ASPNET的一個請求來講從浏覽器向服務器的ASPNET網站發送請求開始一直到最後整個頁面呈現在我們面前其中請求經過的每一個步驟都是有不同的調優方式的而且調用的方法也很多不僅僅只是常見的緩存多線程異步等
本系列的文章決定從兩個大的方面來講述調優
前台調優主要包含如何盡量的減少http請求從http請求開始到如何加載js css如何壓縮傳輸的數據等
後台調優分析ASPNET請求的處理過程並在每一步給出相應的調優方法而且在代碼組織架構和數據庫的操作上面給出調優的方法
記得在剛剛開發網站的時候一提到提高性能最容易也是最快想到的就是緩存而且在微軟官方的Best Practice的一些文檔中也是建議層層緩存(在數據存儲層DALBLLUI等都要緩存)然後在網站中就”緩存遍地開花”最後的確實不盡人意
另外的一個常見的優化針對數據庫的如盡量減少子查詢使用join聯接在常常需要查詢的字段上面建立索引確實這些是很通用也不錯的一些規則
而且還有一個體會就是在優化性能的時候如果選擇優化代碼和數據庫往往優化數據庫的一些操作帶來的效果會更加的好很可惜的是在項目中(至少在我開發的一些項目中)數據庫僅僅就只是一個數據的存儲設備而已僅此而已沒有發揮出數據庫的強大作用所以還是建議對數據庫的內部查詢和存儲的機制要熟悉畢竟很多時候開發人員也擔任了DBA的工作（很多公司沒有正式的DBA）
而且在項目中我們設計數據庫的時候特別是表字段的時候是需要有些考慮的很多人建議表字段的長度不要太長這也是大家常見的建議但是為什麼？其實這就需要懂得一些數據庫的內部存儲機制了在數據庫(SQL SERVER )保存的時候數據是以”頁”為最小的單位的每一頁有K的大小如果你的一個表中的數據超過K那麼這個表的數據就要分幾個頁面保存這樣在對數據進行查詢的時候就要跨頁查詢了跨頁是需要性能消耗的如果數據都在一個頁面上那麼速度肯定快些
所以要優化網站就得知道性能消耗在哪裡
當優化的一個網站的時候不是盲目的一概而論的一般來說有兩種情況
． 網站已經存在了並且運行了現在要優化
． 正在從頭開發一個新的網站
如果是第一種情況那麼首先要找出網站性能的瓶頸從前台的請求的到後台的請求處理一直到最後頁面的呈現都要一步步的審查
如果是第二種情況可能情況就稍微好一點並且網站現在完全由我們控制所有在開發和設計的過程中就可以采用很多的優化原則來優化
優化不一定就是代碼重寫或者做些很大的改動優化時一點點的累積的就好比代碼的重構一樣都是一個積累的效果比如是在頁面一開始的時候載入js腳本還是在整個頁面的最後載入js腳本有時候往往就只是簡單的調整一下載入的文件或者異步的載入腳本或者通過CDN傳輸腳本等等方法性能就提升了性能的提升也不是沒有代價的有的代價很小例如只是把腳本的載入放在頁面最後大的代價就是例如買些服務器設備如Content Delivery Network(CDN)來把靜態的文件(jscssimage)傳送到客戶端所以說優化需要權衡策略
不知道大家是否有過這樣的體會當看著自己開發出來的系統性能很好的時候自己是很自信的相反如果系統很慢有時真不想說這個系統是自己做的
From:http://tw.wingwit.com/Article/program/net/201311/14437.html
