高性能ASP.NET站點構建之性能調優綜述

前言：這段時間，把系列文章又從新整理了一下，以前關於性能優化的介紹一些不是很清晰。能夠說從本篇開始，纔算是一個完整的系列的開始。 

本章的議題以下：

性能調優的通常過程

利用分析工具分析頁面加載信息

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

性能調優的通常過程

在解決性能問題以前首先要確認問題的所在，首先就來看看確保高性能的通常過程：

1.持續監控

2.設定性能目標

3.持續改進

1.持續監控

網站的性能整體來講受兩個方面的影響：

一，咱們能夠控制的，例如代碼；

二，咱們不能控制的，例如訪問用戶的數量，或者服務器自己

特別是隨着站點的訪問量增大的時候，原來沒有出現的問題，如今可能出來了，不一樣的階段要解決的問題也是不同的。因此頗有必要對網站進行持續的監控， 趁早發現網站變慢的緣由。本篇的後面部門會介紹一些咱們可使用的監控服務，來幫助咱們作這些事情。

2． 設定性能目標

網站的性能如何，一個最直觀的感覺就是：打開這個站點以後，頁面加載的時間，這也是說是訪問者最直接的體驗。不少的優化工做（不論是前臺的優化仍是後臺的優化）都是爲了讓用戶更快的看到所想看的頁面和信息。咱們後面的討論不少時候都是以這個爲目標的。

首先必需要明白「快」的含義：一個網站的響應速度多快纔算是「快」？由於優化網站須要花費很大的時間和精力，若是網站自己已經很快了，例如網頁呈現到用戶眼前的時間是毫秒級別的，咱們確實能夠再花時間讓它更快，可是這樣作起來成本會更高!

3．持續改進

在進行性能優化的時候，要涉及到不少的東西，因此在進行優化的時候必須確認：進行的優化措施確實的提升了站點的性能。爲了達到這個目的，有幾個規則能夠遵循：

1. 每次優化只改動一處。若是改動了不少處，那麼這些改動之間可能相互的影響，最後產生一些奇奇怪怪的現象，有時候這些"優化措施"反而使得網站性能下降。並且若是一次改動屢次，也不利於衡量那些"優化措施"真真正正提高了網站的性能。

2. 不斷的測試。每次進行了所謂的"優化"以後，必定要測試一下，這個"優化"是否真的提高了性能，若是沒有提高，那麼就回滾這個操做。

通常進行優化的步驟以下：

1. 記錄如今網站的性能指數和一些相關的數據(後面會告訴你們如何獲取這些性能指數數據)

2. 診斷站點的性能故障點.可能有幾個地方都影響了站點的性能，可是，此時咱們只是選擇影響最大的那個因數進行優化。

3. 解決找出的性能故障點。

4. 測試。收集數據，和優化前進行比較，看看是否提高了性能。

5. 重複1到4步驟。

上面雖然提出了一些規則，可是咱們能夠靈活處理某些狀況：在咱們查找影響性能的問題的時候，咱們發現多個問題，並且這些問題根據咱們的經驗判斷會影響性能，那麼咱們能夠同時修改此處。

咱們用一個流程圖來總結上面的優化步驟。以下：  

下面講述用一些簡單的工具來分析一些與站點性能有關的數據，在上一篇文章中，咱們討論了一下性能調優的通常過程，本篇就開始介紹一些方法和工具，讓你們快速的入門。 

的議題以下：

性能調優的通常過程

利用分析工具分析頁面加載信息

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

利用分析工具分析加載頁面信息 

站點的優化說到底仍是站點每個頁面的優化，即便得站點的頁面更快的呈如今用戶的眼前。因此在此以前，咱們首先來看看一個web頁面的組成部分：

1. Html文件:在ASP.NET中，Html文件一般是經過解析.aspx頁面而產生的。而這個解析過程在服務端進行，同時這個過程也消耗了服務端的大部分資源。

2. 圖片和flash文件：一個站點每每包含不少這樣的的文件。

3. Js和css文件：這些文件能夠阻止頁面的呈現。

清楚了頁面的組成部分以後，咱們能夠把使得頁面加載變慢的因素分爲以下幾類：

1. 服務端的花費大量時間解析.aspx，也就是說服務端產生html文本的時間過長（致使這個問題的緣由不少，例如數據庫查詢很慢，影響了頁面的生成）。

2. 在服務端和瀏覽器之間，傳遞html文本花費大量的時間（例如，頁面中的Viewstate很大，網絡很慢等）。

3. 圖片和flash文件的加載花費大量的時間。

4. Js和css的加載花費大量的時間。

爲了使得一個頁面的加載變快，那麼咱們就得知道：是以上哪個過程影響了速度(本系列的後續文章會詳細講述)。一旦知道了是那類問題致使了性能問題，那麼咱們就能夠對症下藥。

下面咱們就經過一些工具來簡單的查看和分析站點的性能，目的讓你們快速的瞭解如何進行簡單的性能分析。

咱們用瀑布圖來分析頁面的每一個組成部分加載所花的時間，例以下面就是博客園首頁加載的分析圖（部分的截圖）。

咱們能夠經過圖中的「時間線「長短來知道每一個文件加載的時間。時間線長越長，那麼加載該文件的時間越長，反之。

看完了上面的圖以後，你們應該很想知道：上面的圖是如何生成的，那麼下面就介紹一些生成頁面加載瀑布圖的工具。

咱們首先來看看：Firefox+Firebug

Firefox下載地址：http://www.mozilla.com/en-US/firefox/

Firebug下載地址：http://getfirebug.com/

下面就開始演示如何生成頁面加載的瀑布圖（若是熟悉這個流程的朋友能夠跳過此段）

1.  打開Firefox，而後按下F12,就看到以下的畫面：

2.  在Firebug中，在選擇「網絡」下拉框中選擇「啓用」。

OK，下面咱們就來詳細的看看在瀑布圖中一些數據和圖示的意義。

1． 請求和響應的相關信息

在瀑布圖中，點擊每一行的」+」以下：

符號展開以後，咱們能夠看到全部的請求和響應頭，以下：

 2． 時間線的相關信息

當咱們把鼠標移到着色的時間線bar上面的時候，咱們就能夠看到請求該文件所花的時間的詳細信息，以下

咱們用一個表格來說述每一個時間段的含義：

域名解析	尋找請求的文件所在的服務器的IP地址所花的時間
創建鏈接	打開客戶端到服務端的TCP連接所花的時間
發送請求	瀏覽器發送請求所花的時間。你們可能有點奇怪：爲何發送請求還要等待，難道不是打開鏈接就發送了請求嗎？ 其實瀏覽器會把要請求的文件的請求放在請求隊列中，隊列的長度通常都是有限制的，若是頁面須要請求的文件不少，若是隊列達到了最大的限制數量，那麼後續的文件請求會等待。
等待響應	客戶端發送請求一直到接受服務端的第一個字節所花的時間
接受數據	接受整個請求文件或者數據所花的時間
‘DOMContentLoaded’ 事件	從該請求開始進行DNS尋址到整個頁面的DOM被下載下來所花的時間。注意：此時只是頁面的骨架被下載下來了，其中的一些資源（若是圖片，js等）沒有下載下來。當頁面的DOM下載下來了以後，用戶就能夠看到了頁面了，可是有些資源還在陸續的下載中。
‘load’ 事件	從該請求開始進行DNS尋址到整個頁面所有（包括資源）下載下來所花的時間。

3． 頁面級的請求信息

也就是整個頁面的請求的一些彙總信息。

 

下面主要講述如何根據一些簡單的工具和簡單的現象來粗布的定位站點的性能問題。

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

在上一節中，講述瞭如何使用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載入完成以後，頁面開始下載圖片等，此時頁面纔會慢慢的呈現出來。

下圖就反應了這個問題。

 

原文連接：http://www.cnblogs.com/yanyangtian/archive/2011/02/11/1951055.html