高性能ASP.NET站點構(gòu)建之性能調(diào)優(yōu)綜述
高性能ASP.NET站點構(gòu)建系列文章目錄
- 高性能ASP.NET站點構(gòu)建之開篇
- 高性能ASP.NET站點構(gòu)建之剖析頁面的處理過程
- 高性能ASP.NET站點構(gòu)建之優(yōu)化HTTP請求
- 高性能ASP.NET站點構(gòu)建之細節(jié)決定成敗
- 高性能ASP.NET站點構(gòu)建之性能調(diào)優(yōu)綜述
- 高性能ASP.NET站點構(gòu)建之識別性能瓶頸
- 高性能ASP.NET站點構(gòu)建之簡單的優(yōu)化措施
- ASP.NET站點構(gòu)建之減少不必要的請求
- 高性能ASP.NET站點構(gòu)建之托管資源優(yōu)化
- 高性能ASP.NET站點構(gòu)建之監(jiān)測CLR性能
前言：這段時間，把系列文章又重新整理了一下，之前關(guān)于性能優(yōu)化的介紹一些不是很清晰。可以說從本篇開始，才算是一個完整的系列的開始。
本章的議題如下：
性能調(diào)優(yōu)的一般過程
利用分析工具分析頁面加載信息
利用分析工具分析性能瓶頸
性能調(diào)優(yōu)的一般過程
在解決性能問題之前首先要確認問題的所在，首先就來看看確保高性能的一般過程：
1.持續(xù)監(jiān)控
2.設(shè)定性能目標
3.持續(xù)改進
1.持續(xù)監(jiān)控
網(wǎng)站的性能總體來說受兩個方面的影響：
一，我們可以控制的，例如代碼；
二，我們不能控制的，例如訪問用戶的數(shù)量，或者服務(wù)器本身
特別是隨著站點的訪問量增大的時候，原來沒有出現(xiàn)的問題，現(xiàn)在可能出來了，不同的階段要解決的問題也是不一樣的。所以很有必要對網(wǎng)站進行持續(xù)的監(jiān)控， 趁早發(fā)現(xiàn)網(wǎng)站變慢的原因。本篇的后面部門會介紹一些我們可以使用的監(jiān)控服務(wù)，來幫助我們做這些事情。
2． 設(shè)定性能目標
網(wǎng)站的性能如何，一個最直觀的感受就是：打開這個站點之后，頁面加載的時間，這也是說是訪問者最直接的體驗。很多的優(yōu)化工作（不管是前臺的優(yōu)化還是后臺的優(yōu)化）都是為了讓用戶更快的看到所想看的頁面和信息。我們后面的討論很多時候都是以這個為目標的。
首先必須要明白“快”的含義：一個網(wǎng)站的響應(yīng)速度多快才算是“快”？因為優(yōu)化網(wǎng)站需要花費很大的時間和精力，如果網(wǎng)站本身已經(jīng)很快了，例如網(wǎng)頁呈現(xiàn)到用戶眼前的時間是毫秒級別的，我們確實可以再花時間讓它更快，但是這樣做起來成本會更高!
3．持續(xù)改進
在進行性能優(yōu)化的時候，要涉及到很多的東西，所以在進行優(yōu)化的時候必須確認：進行的優(yōu)化措施確實的提高了站點的性能。為了達到這個目的，有幾個規(guī)則可以遵循：
1. 每次優(yōu)化只改動一處。如果改動了很多處，那么這些改動之間可能相互的影響，最后產(chǎn)生一些奇奇怪怪的現(xiàn)象，有時候這些"優(yōu)化措施"反而使得網(wǎng)站性能降低。而且如果一次改動多次，也不利于衡量那些"優(yōu)化措施"真真正正提升了網(wǎng)站的性能。
2. 不斷的測試。每次進行了所謂的"優(yōu)化"之后，一定要測試一下，這個"優(yōu)化"是否真的提升了性能，如果沒有提升，那么就回滾這個操作。
一般進行優(yōu)化的步驟如下：
1. 記錄現(xiàn)在網(wǎng)站的性能指數(shù)和一些相關(guān)的數(shù)據(jù)(后面會告訴大家如何獲取這些性能指數(shù)數(shù)據(jù))
2. 診斷站點的性能故障點.可能有幾個地方都影響了站點的性能，但是，此時我們只是選擇影響最大的那個因數(shù)進行優(yōu)化。
3. 解決找出的性能故障點。
4. 測試。收集數(shù)據(jù)，和優(yōu)化前進行比較，看看是否提升了性能。
5. 重復(fù)1到4步驟。
上面雖然提出了一些規(guī)則，但是我們可以靈活處理某些情況：在我們查找影響性能的問題的時候，我們發(fā)現(xiàn)多個問題，而且這些問題根據(jù)我們的經(jīng)驗判斷會影響性能，那么我們可以同時修改此處。
我們用一個流程圖來總結(jié)上面的優(yōu)化步驟。如下：
下面講述用一些簡單的工具來分析一些與站點性能有關(guān)的數(shù)據(jù)，在上一篇文章中，我們討論了一下性能調(diào)優(yōu)的一般過程，本篇就開始介紹一些方法和工具，讓大家快速的入門。
的議題如下：
性能調(diào)優(yōu)的一般過程
利用分析工具分析頁面加載信息
利用分析工具分析性能瓶頸
利用分析工具分析加載頁面信息
站點的優(yōu)化說到底還是站點每一個頁面的優(yōu)化，即使得站點的頁面更快的呈現(xiàn)在用戶的眼前。所以在此之前，我們首先來看看一個web頁面的組成部分：
1. Html文件:在ASP.NET中，Html文件通常是通過解析.aspx頁面而產(chǎn)生的。而這個解析過程在服務(wù)端進行，同時這個過程也消耗了服務(wù)端的大部分資源。
2. 圖片和flash文件：一個站點往往包含很多這樣的的文件。
3. Js和css文件：這些文件可以阻止頁面的呈現(xiàn)。
清楚了頁面的組成部分之后，我們可以把使得頁面加載變慢的因素分為如下幾類：
1. 服務(wù)端的花費大量時間解析.aspx，也就是說服務(wù)端產(chǎn)生html文本的時間過長（導(dǎo)致這個問題的原因很多，例如數(shù)據(jù)庫查詢很慢，影響了頁面的生成）。
2. 在服務(wù)端和瀏覽器之間，傳遞html文本花費大量的時間（例如，頁面中的Viewstate很大，網(wǎng)絡(luò)很慢等）。
3. 圖片和flash文件的加載花費大量的時間。
4. Js和css的加載花費大量的時間。
為了使得一個頁面的加載變快，那么我們就得知道：是以上哪一個過程影響了速度(本系列的后續(xù)文章會詳細講述)。一旦知道了是那類問題導(dǎo)致了性能問題，那么我們就可以對癥下藥。
下面我們就通過一些工具來簡單的查看和分析站點的性能，目的讓大家快速的了解如何進行簡單的性能分析。
我們用瀑布圖來分析頁面的每個組成部分加載所花的時間，例如下面就是博客園首頁加載的分析圖（部分的截圖）。
我們可以通過圖中的“時間線“長短來知道每個文件加載的時間。時間線長越長，那么加載該文件的時間越長，反之。
看完了上面的圖之后，大家應(yīng)該很想知道：上面的圖是如何生成的，那么下面就介紹一些生成頁面加載瀑布圖的工具。
我們首先來看看：Firefox+Firebug
Firefox下載地址：http://www.mozilla.com/en-US/firefox/
Firebug下載地址：http://getfirebug.com/
下面就開始演示如何生成頁面加載的瀑布圖（如果熟悉這個流程的朋友可以跳過此段）
1. 打開Firefox，然后按下F12,就看到如下的畫面：
2. 在Firebug中，在選擇“網(wǎng)絡(luò)”下拉框中選擇“啟用”。
OK，下面我們就來詳細的看看在瀑布圖中一些數(shù)據(jù)和圖示的意義。
1． 請求和響應(yīng)的相關(guān)信息
在瀑布圖中，點擊每一行的”+”如下：
符號展開之后，我們可以看到所有的請求和響應(yīng)頭，如下：
2． 時間線的相關(guān)信息
當我們把鼠標移到著色的時間線bar上面的時候，我們就可以看到請求該文件所花的時間的詳細信息，如下
我們用一個表格來講述每個時間段的含義：
|
域名解析 |
尋找請求的文件所在的服務(wù)器的IP地址所花的時間 |
|
建立連接 |
打開客戶端到服務(wù)端的TCP鏈接所花的時間 |
|
發(fā)送請求 |
瀏覽器發(fā)送請求所花的時間。大家可能有點奇怪：為什么發(fā)送請求還要等待，難道不是打開連接就發(fā)送了請求嗎？ 其實瀏覽器會把要請求的文件的請求放在請求隊列中，隊列的長度一般都是有限制的，如果頁面需要請求的文件很多，如果隊列達到了最大的限制數(shù)量，那么后續(xù)的文件請求會等待。 |
|
等待響應(yīng) |
客戶端發(fā)送請求一直到接受服務(wù)端的第一個字節(jié)所花的時間 |
|
接受數(shù)據(jù) |
接受整個請求文件或者數(shù)據(jù)所花的時間 |
|
‘DOMContentLoaded’ 事件 |
從該請求開始進行DNS尋址到整個頁面的DOM被下載下來所花的時間。注意：此時只是頁面的骨架被下載下來了，其中的一些資源（如果圖片，js等）沒有下載下來。當頁面的DOM下載下來了之后，用戶就可以看到了頁面了，但是有些資源還在陸續(xù)的下載中。 |
|
‘load’ 事件 |
從該請求開始進行DNS尋址到整個頁面全部（包括資源）下載下來所花的時間。 |
3． 頁面級的請求信息
也就是整個頁面的請求的一些匯總信息。
#p#
下面主要講述如何根據(jù)一些簡單的工具和簡單的現(xiàn)象來粗布的定位站點的性能問題。
利用分析工具分析性能瓶頸
在上一節(jié)中，講述了如何使用Firebug來生成頁面加載信息的瀑布圖，同時也講述了使得頁面加載變慢的四個大的問題
1. 服務(wù)端花費大量時間解析.aspx時間過長。
2. 在服務(wù)端和瀏覽器之間，傳遞html時間過長
3. 圖片和flash文件的加載時間過長
4. Js和css的加載花費時間過長
那么我們下面就根據(jù)瀑布圖來判斷：頁面加載變慢，到底是因為哪個因素導(dǎo)致的。
1. 如何判斷：服務(wù)端花費大量時間解析.aspx時間過長。
在下面的圖示中，大家可以看到第一條時間線特別的長：其中紫色的那段表明了在瀏覽器接受到該頁面的第一個字節(jié)之前等待的時間。也就是說，在瀏覽器請求Default.aspx頁面之后，瀏覽器一直處于等待狀態(tài)。只有瀏覽器接受到了Default.aspx的DOM之后，才開始下載頁面中的其他的資源(css,圖片等)。如果在接受Default.aspx的DOM之前等待的時間過長，那么勢必影響其他的資源的下載，最后導(dǎo)致整個頁面的加載變慢。
如果我們在用firebug生成瀑布圖的時候，發(fā)現(xiàn)了上面的類似的現(xiàn)象，頁面加載變慢的原因很有可能就是服務(wù)端在解析Default.aspx頁面，生成html文本的時間太長了。至于是什么原因?qū)е铝朔?wù)端解析Default.aspx時間過長，那么需要進一步的分析。可能是代碼寫的不好，例如循環(huán)問題；可能是數(shù)據(jù)庫問題，例如查詢數(shù)據(jù)太慢或者數(shù)據(jù)太多等（后續(xù)文章詳細講述）。
注：顏色表示的意思：
2. 如何判斷：在服務(wù)端和瀏覽器之間，傳遞html時間過長
在下面的圖中，大家可以看到紫色的線段比較的短，也就是說，服務(wù)端解析Default.aspx頁面的時間還是比較短的，但是灰色的線段比較的長，。灰色的部分表示接受數(shù)據(jù)時間很長，也就是說服務(wù)端把DOM發(fā)送到瀏覽器，這個過程耗時比較的長。正如之前的問題一樣，這個問題也會推遲頁面的其他的資源下載，導(dǎo)致整個頁面加載過慢。導(dǎo)致這個問題的原因可能是帶寬問題，可能是數(shù)據(jù)過多等。
3. 如何判斷：圖片和flash等文件的加載時間過長
如下圖所示，頁面的解析和傳送到客戶端的時間比較的短，但是頁面中的圖片加載花費了大量的時間。現(xiàn)在的瀏覽器一般都會同時打開多個鏈接，并行的請求多個圖片資源，而不是一個個的挨個請求。但是瀏覽器打開鏈接的數(shù)量是有限制的（不同的瀏覽器不一樣），而且打開新的TCP鏈接也是需要花時間的，不是鏈接越多越好。后面我們會講述如何減少圖片等資源的加載時間。
4. 如何判斷：Js和css的加載花費時間過長，阻止頁面的呈現(xiàn)
如下圖所示，在Default.aspx頁面載入之后，瀏覽器就開始解析DOM（從上到下解析，例如head -> body…）,下載資源。當頁面解析到需要加載css和js時，此時瀏覽器就會去服務(wù)端請求這些文件，而用戶在瀏覽器中看到的Default頁面將會是一片空白，一直到css和js載入完成之后，頁面開始下載圖片等，此時頁面才會慢慢的呈現(xiàn)出來。
下圖就反應(yīng)了這個問題。
原文鏈接：http://www.cnblogs.com/yanyangtian/archive/2011/02/11/1951055.html
