建構高性能的ASP.NET應用（五）-如何開始尋找性能瓶頸

既然我們講的是如何建構高性能的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> 等，此時浏覽器再次發送請求，擷取資源。一步步的，最後一直把整個頁面全部解析完成，資源加載完成，展示在使用者眼前。

問題解析

了解了這個過程，我們再次回到之前的問題。我們可以知道頁面中不同的組成部分，對應的問題是不一樣的，大緻可以分為下面幾類：

如果Html的産生過慢，那麼，使用者勢必會花很長時間才能看到頁面。如圖：

同理，如果頁面（頁面的html文本内容）的傳輸過慢，那麼，最後整個頁面的解析也會往後面推遲，最後也導緻使用者很長時間之後才能看到頁面，如圖：

另外，圖檔和flash等資源的加載有問題，那麼一方面會讓使用者看到這些資源，另外也會增加伺服器的負擔。如圖：

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應用（四）-性能的優化的目标