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