轉：構建高效能ASP.NET網站 開篇

本篇的議題如下:

網站最佳化需要考慮的方面

 

網站最佳化需要考慮的方面

 

在用ASP.NET開發網站的時候,效能是永遠需要考慮和關注的問題,效能不僅僅只是程式碼執行時候的速度，而是涉及到方方面面的東西。

 

就拿ASP.NET的一個請求來講，從瀏覽器向伺服器的ASP.NET網站發送請求開始一直到最後整個頁面呈現在我們面前，其中請求經過的每一個步驟，都是有不同的調優方式的，而且調用的方法也很多，不僅僅只是常見的：緩衝，多線程，非同步等。

 

本系列的文章決定從兩個大的方面來講述調優：

前台調優：主要包含如何盡量的減少http請求，從http請求開始，到如何載入js, css，如何壓縮傳輸的資料等。

 

後台調優：分析ASP.NET請求的處理過程，並在每一步給出相應的調優方法，而且在程式碼群組織，架構和資料庫的操作上面給出調優的方法。

 

記得在剛剛開發網站的時候，一提到提高效能，最容易也是最快想到的就是緩衝，而且在微軟官方的Best Practice的一些文檔中也是建議：層層緩衝(在資料存放區層，DAL,BLL,UI等都要緩衝)。然後在網站中就”緩衝遍地開花”，最後的確實不盡人意。

 

另外的一個常見的最佳化針對資料庫的：如盡量減少子查詢，使用join聯結；在常常需要查詢的欄位上面建立索引。確實，這些是很通用，也不錯的一些規則。

 

而且還有一個體會就是，在最佳化效能的時候，如果選擇最佳化代碼和資料庫，往往最佳化資料庫的一些操作帶來的效果會更加的好，很可惜的是：在項目中(至少在我開發的一些項目中)，資料庫僅僅就只是一個資料的存放裝置而已，僅此而已，沒有發揮出資料庫的強大作用。所以還是建議對資料庫的內部查詢和儲存的機制要熟悉，畢竟很多時候開發人員也擔任了DBA的工作（很多公司沒有正式的DBA）。

 

而且在項目中我們設計資料庫的時候，特別是表欄位的時候，是需要有些考慮的，很多人建議表欄位的長度不要太長，這也是大家常見的建議，但是為什嗎？其實，這就需要懂得一些資料庫的內部儲存機制了：在資料庫(SQL SERVER )儲存的時候，資料是以”頁”為最小的單位的，每一頁有8K的大小，如果你的一個表中的資料超過8K，那麼這個表的資料就要分幾個頁面儲存，這樣在對資料進行查詢的時候，就要跨頁查詢了，跨頁是需要效能消耗的，如果資料都在一個頁面上，那麼速度肯定快些。

 

所以，要最佳化網站，就得知道效能消耗在哪裡。

 

當最佳化的一個網站的時候，不是盲目的一概而論的，一般來說有兩種情況：

1． 網站已經存在了，並且運行了，現在要最佳化。

2． 正在從頭開發一個新的網站。

 

如果是第一種情況，那麼首先要找出網站效能的瓶頸，從前台的請求的到背景請求處理，一直到最後頁面的呈現，都要一步步的審查。

 

如果是第二種情況，可能情況就稍微好一點，並且網站現在完全由我們控制，所有在開發和設計的過程中就可以採用很多的最佳化原則來最佳化。

 

最佳化不一定就是代碼重寫或者做些很大的改動，最佳化時一點點的累積的，就好比代碼的重構一樣，都是一個積累的效果。比如，是在頁面一開始的時候載入js指令碼，還是在整個頁面的最後載入js指令碼，有時候往往就只是簡單的調整一下載入的檔案，或者非同步載入指令碼，或者通過CDN傳輸指令碼等等方法，效能就提升了。效能的提升也不是沒有代價的，有的代價很小，例如只是把指令碼的載入放在頁面最後，大的代價就是，例如買些伺服器裝置，如Content Delivery Network(CDN)來把靜態檔案(js,css,image)傳送到用戶端。所以說，最佳化需要權衡策略。

 

不知道大家是否有過這樣的體會：當看著自己開發出來的系統效能很好的時候，自己是很自信的，相反，如果系統很慢，有時真不想說這個系統是自己做的。

 

本篇是系列開篇，只是閑談了一些最佳化的一些話題，實際的知識沒有講多少，希望大家見諒。

下篇開始，我們就開始最佳化之旅，敬請關注！ ：）

 

轉：http://www.cnblogs.com/yanyangtian/archive/2010/07/16/1778986.html