高性能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站點構建之監測CLR性能
前言：這段時間，把系列文章又重新整理了一下，之前關于性能優化的介紹一些不是很清晰。可以說從本篇開始，才算是一個完整的系列的開始。
本章的議題如下：
性能調優的一般過程
利用分析工具分析頁面加載信息
利用分析工具分析性能瓶頸
性能調優的一般過程
在解決性能問題之前首先要確認問題的所在，首先就來看看確保高性能的一般過程：
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． 頁面級的請求信息
也就是整個頁面的請求的一些匯總信息。
#p#
下面主要講述如何根據一些簡單的工具和簡單的現象來粗布的定位站點的性能問題。
利用分析工具分析性能瓶頸
在上一節中，講述了如何使用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
