【原創】構建高效能ASP.NET網站 開篇

 

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

 

　　前言:有段時間沒有寫ASP.NET的東西了,心裡總是覺得缺少了什麼,畢竟自己對ASP.NET還是情有獨鐘的. 在本系列文章中,準備比較全面的講述ASP.NET的效能的最佳化,從前台到後台,以後本列文也看作為大家的一個手冊來查詢!

 

 

　　系列文章連結：

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

　　構建高效能ASP.NET網站之一 剖析頁面的處理過程（前端）

　　構建高效能ASP.NET網站之二 最佳化HTTP請求(前端)

　　構建高效能ASP.NET網站之三 細節決定成敗

　　構建高效能ASP.NET網站 第五章—效能調優綜述（前篇）

　　大型高效能ASP.NET系統架構設計  

　　構建高效能ASP.NET網站 第五章—效能調優綜述（中篇）

　　構建高效能ASP.NET網站 第五章—效能調優綜述（後篇） 

　　構建高效能ASP.NET網站 第六章—效能瓶頸診斷與初步調優（上篇）—識別效能瓶頸

　　構建高效能ASP.NET網站 第六章—效能瓶頸診斷與初步調優（下前篇）—簡單的最佳化措施

　　構建高效能ASP.NET網站 第六章—效能瓶頸診斷與初步調優（下後篇）—減少不必要的請求

　　構建高效能ASP.NET網站 第七章 如何解決記憶體的問題(前篇)—託管資源最佳化—記憶體回收機制深度剖析

　　構建高效能ASP.NET網站 第七章 如何解決記憶體的問題(前中篇)—託管資源最佳化—監測CLR效能

 

 

 

本篇的議題如下:

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

 

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

 

在用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