建構高性能的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等資源的加載有問題，那麼一方面會讓使用者看到這些資源，另外也會增加伺服器的負擔。如圖：

問題的分類

看完了上面簡單的分析之後，我們可以再次思考，把上面的問題進行分類。因為上面的問題的産生，肯定有一個最後歸根究底的原因的，我們可以通過上面的分析，把他們這些原因對應上，如圖：

在我們後續的講解中，更多的從上圖中的内容進行讨論。

從這裡就驗證了我們之前講述的很多的内容：分析問題要順藤摸瓜，由表及裡的分析.

更多：

<a href="http://www.agilesharp.com/showtopic-485.aspx">建構高性能的ASP.NET應用（一）-先把思路搞對，然後對症下藥</a>

<a href="http://www.agilesharp.com/showtopic-487.aspx">建構高性能的ASP.NET應用（二）-性能優化演繹法</a>

<a href="http://www.agilesharp.com/showtopic-489.aspx">建構高性能的ASP.NET應用（三）-從監控出發，讓一切用資料說話</a>

本文轉自yanyangtian51CTO部落格，原文連結： http://blog.51cto.com/yanyangtian/1152169，如需轉載請自行聯系原作者