【原創】構建高效能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效能

 

 

 

 

　　利用分析工具分析效能瓶頸

    在上一節中，講述了如何使用Firebug來產生頁面載入資訊的瀑布圖，同時也講述了使得頁面載入變慢的四個大的問題：

1.       服務端花費大量時間解析.aspx時間過長。

2.       在服務端和瀏覽器之間，傳遞html時間過長

3.       圖片和flash檔案的載入時間過長

4.       Js和css的載入花費時間過長

    那麼我們下面就根據瀑布圖來判斷：頁面載入變慢，到底是因為哪個因素導致的。

 

1.       如何判斷：服務端花費大量時間解析.aspx時間過長。

在下面的圖示中，大家可以看到第一條時間軸特別的長：其中紫色的那段表明了在瀏覽器接受到該頁面的第一個位元組之前等待的時間。也就是說，在瀏覽器請求Default.aspx頁面之後，瀏覽器一直處於等待狀態。只有瀏覽器接受到了Default.aspx的DOM之後，才開始下載頁面中的其他的資源(css,圖片等)。如果在接受Default.aspx的DOM之前等待的時間過長，那麼勢必影響其他的資源的下載，最後導致整個頁面的載入變慢。

 

 

 

如果我們在用firebug產生瀑布圖的時候，發現了上面的類似的現象，頁面載入變慢的原因很有可能就是服務端在解析Default.aspx頁面，產生html文本的時間太長了。至於是什麼原因導致了服務端解析Default.aspx時間過長，那麼需要進一步的分析。可能是代碼寫的不好，例如迴圈問題；可能是資料庫問題，例如查詢資料太慢或者資料太多等（後續文章詳細講述）。  

 

註：顏色表示的意思：

 

 

 

2.       如何判斷：在服務端和瀏覽器之間，傳遞html時間過長

    在下面的圖中，大家可以看到紫色的線段比較的短，也就是說，服務端解析Default.aspx頁面的時間還是比較短的，但是灰色的線段比較的長，。灰色的部分表示接受資料時間很長，也就是說服務端把DOM發送到瀏覽器，這個過程耗時比較的長。正如之前的問題一樣，這個問題也會延遲頁面的其他的資源下載，導致整個頁面載入過慢。導致這個問題的原因可能是頻寬問題，可能是資料過多等。

 

 

 

3.       如何判斷：圖片和flash等檔案的載入時間過長

如所示，頁面的解析和傳送到用戶端的時間比較的短，但是頁面中的圖片載入花費了大量的時間。現在的瀏覽器一般都會同時開啟多個連結，並行的請求多個圖片資源，而不是一個個的挨個請求。但是瀏覽器開啟連結的數量是有限制的（不同的瀏覽器不一樣），而且開啟新的TCP連結也是需要花時間的，不是連結越多越好。後面我們會講述如何減少圖片等資源的載入時間。

 

 

 

4.       如何判斷：Js和css的載入花費時間過長，阻止頁面的呈現

    如所示，在Default.aspx頁面載入之後，瀏覽器就開始解析DOM（從上到下解析，例如head -> body…）,下載資源。當頁面解析到需要載入css和js時，此時瀏覽器就會去服務端請求這些檔案，而使用者在瀏覽器中看到的Default頁面將會是一片空白，一直到css和js載入完成之後，頁面開始下載圖片等，此時頁面才會慢慢的呈現出來。

就反應了這個問題。

 

  

   今天就到這裡了，從下一篇文章開始就全面進入分析和調優階段。