既然我們講的是如何構建高效能的ASP.NET網站應用,那麼我們就開始涉及網站方面的東西。我們說過,我們會把關注點放在“調優”上面。
在調優的時候,我們沒有必要把事情搞的很複雜,要“由表及裡。從整體到局部”。對於一個網站而言,我們最直接看到的就是網站的頁面。換句話說,如果網站效能處理問題,肯定在頁面上面會有反應。一個最顯而易見的反應就是:頁面載入很慢,半天看不到內容。
此時,我們可以進一步的分析,頁面載入很慢,是什麼原因導致的?
這裡還是從最簡單的方面入手。沒有必要想的很複雜,我們要清楚:頁面是由什麼組成的?
很顯而易見,一個頁面,無非就是由Html文本,圖片或者Flash,還有JS和CSS組成。換句話說,如果頁面載入很慢,那麼問題就出現在這些頁面的這些組成部分上面。
頁面解析過程
為了更好的說明,我們先來看看一個頁面的載入的過程。
1. 當使用者在瀏覽器地址輸入一個地址,然後enter。
2. 此時瀏覽器首先會去進行網域名稱解析,要麼讀取本地的DNS緩衝,或者去遠程網路上面解析,最後的結果就是把網域名稱對應的IP地址得到。
3. 得到了IP地址之後,瀏覽器就開始發送請求,建立TCP串連,經過三向交握之後,串連就建立了。
4. TCP串連建立之後,瀏覽器就把請求發送過去。
5. 服務端接收到請求之後,就開始處理,例如,如果請求的是一個頁面(不管是動態還是靜態),最後的結果就是:服務端把響應發送發送給用戶端。
6. 在響應中,先發送的是回應標頭,之後就開始傳遞html內容。
7. Html內容經過網路傳輸到了用戶端瀏覽器之後,瀏覽器就開始載入網頁的內容,開始呈現。產生的頁面的內容html文本是以流的形式傳遞的,通俗的說就是一點點的傳輸的,直到html文本傳遞完成,此時頁面裡面所有的資源還是沒有載入的,只是頁面的html骨架載入完成了。
所以瀏覽器這邊收到html內容之後就開始解析html,而且是從上到下進行解析的:先解析html標記,然後解析head,然後解析body…
在解析的過程之後,如果遇到要去載入資源的標記,例如<script>,<img> 等,此時瀏覽器再次發送請求,擷取資源。一步步的,最後一直把整個頁面全部解析完成,資源載入完成,展示在使用者眼前。
20130311161225.png(60.97 K)2013/3/11 16:59:18
問題解析
理解了這個過程,我們再次回到之前的問題。我們可以知道頁面中不同的組成部分,對應的問題是不一樣的,大致可以分為下面幾類:
20130311164741.png(9.89 K)2013/3/11 16:48:58
如果Html的產生過慢,那麼,使用者勢必會花很長時間才能看到頁面。
20130311164102.png(39.95 K)2013/3/11 16:48:58
同理,如果頁面(頁面的html常值內容)的傳輸過慢,那麼,最後整個頁面的解析也會往後面延遲,最後也導致使用者很長時間之後才能看到頁面,
20130311164111.png(48.61 K)2013/3/11 16:48:58
另外,圖片和flash等資源的載入有問題,那麼一方面會讓使用者看到這些資源,另外也會增加伺服器的負擔。
20130311164546.png(24.76 K)2013/3/11 16:48:58
Js和css的載入是個特別要注意的問題,因為js的載入是很“霸道“的:如果此時,在解析頁面的html的時候,看到了<script scr="www.agilesharp.com/js/ag.js/> 此時,瀏覽器就會發送請求去擷取這個指令碼,而且此時瀏覽器不會繼續解析後面的頁面內容,而是等到這個js回來之後,才能繼續往下走。這就是為什麼很多時候我們總是把一些不必要的指令碼放在頁面的最後載入的原因。而對於css而言,它不霸道,在載入css的同時,瀏覽器可以繼續往下面走,解析下面的頁面內容。
問題的分類
看完了上面簡單的分析之後,我們可以再次思考,把上面的問題進行分類。因為上面的問題的產生,肯定有一個最後歸根究底的原因的,我們可以通過上面的分析,把他們這些原因對應上,
20130311165048.png(26.23 K)2013/3/11 16:59:04
在我們後續的講解中,更多的從中的內容進行討論。
從這裡就驗證了我們之前講述的很多的內容:分析問題要順藤摸瓜,由表及裡的分析.
更多:
構建高效能的ASP.NET應用(一)-先把思路搞對,然後對症下藥
構建高效能的ASP.NET應用(二)-效能最佳化演繹法
構建高效能的ASP.NET應用(三)-從監控出發,讓一切用資料說話
構建高效能的ASP.NET應用(四)-效能的最佳化的目標