Web性能测试
Web性能測試
負(fù)載測試：在被測系統(tǒng)上不斷增加壓力 ，直到性能指標(biāo)達(dá)到極限，響應(yīng)時間超過預(yù)定指
標(biāo)或者某種資源已經(jīng)達(dá)到飽和狀態(tài)。這種測試可以找到系統(tǒng)的處理極限，為系統(tǒng)調(diào)優(yōu)提供
依據(jù)。
大數(shù)據(jù)量測試：針對某些系統(tǒng)存儲、傳輸、統(tǒng)計查詢等業(yè)務(wù)進(jìn)行大數(shù)據(jù)量的測試。
配置測試：通過測試找到系統(tǒng)各資源的最優(yōu)分配原則。
可靠性測試：可以施加cpu資源保持70%-90%使用率的壓力，連續(xù)對系統(tǒng)加壓運(yùn)行8小時，
然后根據(jù)結(jié)果分析系統(tǒng)是否穩(wěn)定。即加載一定壓力的情況下，使系統(tǒng)運(yùn)行一段時間。
并發(fā)測試：多以發(fā)現(xiàn)一些算法設(shè)計上的問題。
性能測試以用戶并發(fā)測試為主的測試。
性能測試主要是為了發(fā)現(xiàn)軟件問題和硬件瓶頸。
二 web性能測試基本性能指標(biāo)
<一> Web性能測試的部分概況一般來說，一個Web請求的處理包括以下步驟：
（1）客戶發(fā)送請求
（2）web server接受到請求，進(jìn)行處理；
（3）web server向DB獲取數(shù)據(jù)；
（4）webserver生成用戶的object(頁面)，返回給用戶。給客戶發(fā)送請求開始到最后一個
字節(jié)的時間稱為響應(yīng)時間（第三步不包括在每次請求處理中）。
<二>
1.事務(wù)（Transaction）
在web性能測試中，一個事務(wù)表示一個“從用戶發(fā)送請求->web server接受到請求，進(jìn)行
處理-> web server向DB獲取數(shù)據(jù)->生成用戶的object(頁面)，返回給用戶”的過程，一
般的響應(yīng)時間都是針對事務(wù)而言的。
2.請求響應(yīng)時間
請求響應(yīng)時間指的是從客戶端發(fā)起的一個請求開始，到客戶端接收到從服務(wù)器端返回的響
應(yīng)結(jié)束，這個過程所耗費的時間，在某些工具中，響應(yīng)通常會稱為“TTLB”，即"time to?
last byte"，意思是從發(fā)起一個請求開始，到客戶端接收到最后一個字節(jié)的響應(yīng)所耗費的
時間，響應(yīng)時間的單位一般為“秒”或者“毫秒”。一個公式可以表示：響應(yīng)時間＝網(wǎng)絡(luò)
響應(yīng)時間+應(yīng)用程序響應(yīng)時間。標(biāo)準(zhǔn)可參考國外的3/5/10原則：
（1）在3秒鐘之內(nèi)，頁面給予用戶響應(yīng)并有所顯示，可認(rèn)為是“很不錯的”；
（2）在3~5秒鐘內(nèi)，頁面給予用戶響應(yīng)并有所顯示，可認(rèn)為是“好的”；
（3）在5~10秒鐘內(nèi)，頁面給予用戶響應(yīng)并有所顯示，可認(rèn)為是“勉強(qiáng)接受的”；
（4）超過10秒就讓人有點不耐煩了，用戶很可能不會繼續(xù)等待下去；
3、事務(wù)響應(yīng)時間
? 事務(wù)可能由一系列請求組成,事務(wù)的響應(yīng)時間主要是針對用戶而言,屬于宏觀上的概念，
是為了向用戶說明業(yè)務(wù)響應(yīng)時間而提出的.例如:跨行取款事務(wù)的響應(yīng)時間就是由一系列的
請求組成的.事務(wù)響應(yīng)時間是直接衡量系統(tǒng)性能的參數(shù).
4.并發(fā)用戶數(shù)
并發(fā)一般分為2種情況。一種是嚴(yán)格意義上的并發(fā)，即所有的用戶在同一時刻做同一件事
情或者操作，這種操作一般指做同一類型的業(yè)務(wù)。比如在信用卡審批業(yè)務(wù)中，一定數(shù)目的
擁護(hù)在同一時刻對已經(jīng)完成的審批業(yè)務(wù)進(jìn)行提交；還有一種特例，即所有用戶進(jìn)行完全一
樣的操作，例如在信用卡審批業(yè)務(wù)中，所有的用戶可以一起申請業(yè)務(wù)，或者修改同一條記
錄。
另外一種并發(fā)是廣義范圍的并發(fā)。這種并發(fā)與前一種并發(fā)的區(qū)別是，盡管多個用戶對
系統(tǒng)發(fā)出了請求或者進(jìn)行了操作，但是這些請求或者操作可以是相同的，也可以是不同的
。對整個系統(tǒng)而言，仍然是有很多用戶同時對系統(tǒng)進(jìn)行操作，因此也屬于并發(fā)的范疇。
可以看出，后一種并發(fā)是包含前一種并發(fā)的。而且后一種并發(fā)更接近用戶的實際使用
情況，因此對于大多數(shù)的系統(tǒng)，只有數(shù)量很少的用戶進(jìn)行“嚴(yán)格意義上的并發(fā)”。對于
WEB性能測試而言，這2種并發(fā)情況一般都需要進(jìn)行測試，通常做法是先進(jìn)行嚴(yán)格意義上的
并發(fā)測試。嚴(yán)格意義上的用戶并發(fā)一般發(fā)生在使用比較頻繁的模塊中，盡管發(fā)生的概率不
是很大，但是一旦發(fā)生性能問題，后果很可能是致命的。嚴(yán)格意義上的并發(fā)測試往往和功
能測試關(guān)聯(lián)起來，因為并發(fā)功能遇到異常通常都是程序問題，這種測試也是健壯性和穩(wěn)定
性測試的一部分。
用戶并發(fā)數(shù)量：關(guān)于用戶并發(fā)的數(shù)量，有2種常見的錯誤觀點。 一種錯誤觀點是把并發(fā)用
戶數(shù)量理解為使用系統(tǒng)的全部用戶的數(shù)量，理由是這些用戶可能同時使用系統(tǒng)；還有一種
比較接近正確的觀點是把在線用戶數(shù)量理解為并發(fā)用戶數(shù)量。實際上在線用戶也不一定會
和其他用戶發(fā)生并發(fā)，例如正在瀏覽網(wǎng)頁的用戶，對服務(wù)器沒有任何影響，但是，在線用
戶數(shù)量是計算并發(fā)用戶數(shù)量的主要依據(jù)之一。
5.吞吐量
指的是在一次性能測試過程中網(wǎng)絡(luò)上傳輸?shù)臄?shù)據(jù)量的總和.吞吐量/傳輸時間,就是吞吐率.
6、 TPS（transactionper second）
每秒鐘系統(tǒng)能夠處理的交易或者事務(wù)的數(shù)量.它是衡量系統(tǒng)處理能力的重要指標(biāo).
7、點擊率
每秒鐘用戶向WEB服務(wù)器提交的HTTP請求數(shù).這個指標(biāo)是WEB應(yīng)用特有的一個指標(biāo):WEB應(yīng)用
是"請求-響應(yīng)"模式,用戶發(fā)出一次申請,服務(wù)器就要處理一次,所以點擊是WEB應(yīng)用能夠處
理的交易的最小單位.如果把每次點擊定義為一個交易,點擊率和TPS就是一個概念.容易看
出,點擊率越大,對服務(wù)器的壓力越大.點擊率只是一個性能參考指標(biāo),重要的是分析點擊時
產(chǎn)生的影響。需要注意的是,這里的點擊并非指鼠標(biāo)的一次單擊操作,因為在一次單擊操作
中,客戶端可能向服務(wù)器發(fā)出多個HTTP請求.
8.資源利用率
指的是對不同的系統(tǒng)資源的使用程度,例如服務(wù)器的CPU利用率,磁盤利用率等.資源利用率
是分析系統(tǒng)性能指標(biāo)進(jìn)而改善性能的主要依據(jù),因此是WEB性能測試工作的重點.
資源利用率主要針對WEB服務(wù)器,操作系統(tǒng),數(shù)據(jù)庫服務(wù)器,網(wǎng)絡(luò)等,是測試和分析瓶頸的主
要參考.在WEB性能測試中,更根據(jù)需要采集相應(yīng)的參數(shù)進(jìn)行分析。
通用指標(biāo)（指Web應(yīng)用服務(wù)器、數(shù)據(jù)庫服務(wù)器必需測試項)
指標(biāo)
說明
ProcessorTime 服務(wù)器CPU占用率，一般平均達(dá)到70%時，服務(wù)就接近飽和
Memory Available Mbyte 可用內(nèi)存數(shù)，如果測試時發(fā)現(xiàn)內(nèi)存有變化情況也要注意，如果
是內(nèi)存泄露則比較嚴(yán)重
Physicsdisk Time 物理磁盤讀寫時間情況
Web服務(wù)器指標(biāo)
指標(biāo)
說明
Requests Per Second（Avg Rps） 平均每秒鐘響應(yīng)次數(shù)＝總請求時間 / 秒數(shù)
Avg time to last byte per terstion （mstes） 平均每秒業(yè)務(wù)腳本的迭代次數(shù) ,有
人會把上面那個混淆
Successful Rounds 成功的請求
Failed Requests 失敗的請求
Successful Hits 成功的點擊次數(shù)
Failed Hits 失敗的點擊次數(shù)
Hits Per Second 每秒點擊次數(shù)
Successful Hits Per Second 每秒成功的點擊次數(shù)
Failed Hits Per Second 每秒失敗的點擊次數(shù)
Attempted Connections 嘗試鏈接數(shù)
數(shù)據(jù)庫服務(wù)器性能指標(biāo)
指標(biāo)
說明
User 0 Connections 用戶連接數(shù)，也就是數(shù)據(jù)庫的連接數(shù)量
Number of deadlocks 數(shù)據(jù)庫死鎖
Butter Cache hit 數(shù)據(jù)庫Cache的命中情況
系統(tǒng)的瓶頸定義
性能項
命令
指標(biāo)
CPU限制 vmstat 當(dāng)%user+%sys超過80%時
磁盤I/O限制 Vmstat 當(dāng)%iowait超過40%(AIX4.3.3或更高版本)時
應(yīng)用磁盤限制 Iostat 當(dāng)%tm_act超過70%時
虛存空間少 Lsps，-a 當(dāng)分頁空間的活動率超過70%時
換頁限制 Iostat, stat 虛存邏輯卷%tm_act超過I/O(iostat)的30%，激活的
虛存率超過CPU數(shù)量(vmstat)的10倍時
系統(tǒng)失效 Vmstat, sar 頁交換增大、CPU等待并運(yùn)行隊列
穩(wěn)定系統(tǒng)的資源狀態(tài)
性能項
資源
評價
CPU占用率 70% 好
85% 壞
90%+ 很差
磁盤I/0 <30% 好
<40% 壞
<50%+ 很差
網(wǎng)絡(luò) <30%帶寬 好
運(yùn)行隊列 <2*CPU數(shù)量 好
內(nèi)存 沒有頁交換 好
每個CPU每秒10個頁交換 壞
更多的頁交換 很差
通俗理解：
日訪問量
常用頁面最大并發(fā)數(shù)
同時在線人數(shù)
訪問相應(yīng)時間
案例：
最近公司一個項目，是個門戶網(wǎng)站，需要做性能測試，根據(jù)項目特點定出了主要測試
項和測試方案：
一種是測試幾個常用頁面能接受的最大并發(fā)數(shù)(用戶名參數(shù)化，設(shè)置集合點策略)
一種是測試服務(wù)器長時間壓力下，用戶能否正常操作(用戶名參數(shù)化，迭代運(yùn)行腳本)
一種則需要測試服務(wù)器能否接受10萬用戶同時在線操作，如果是用IIS做應(yīng)用服務(wù)器
的話，單臺可承受的最大并發(fā)數(shù)不可能達(dá)到10萬級，那就必須要使用集群，通過多臺機(jī)器
做負(fù)載均衡來實現(xiàn)；如果是用websphere之類的應(yīng)用服務(wù)器的話，單臺可承受的最大并發(fā)
數(shù)可以達(dá)到10萬級，但為性能考慮還是必須要使用集群，通過多臺機(jī)器做負(fù)載均衡來實現(xiàn)
；通常有1個簡單的計算方式，1個連接產(chǎn)生1個session，每個session在服務(wù)器上有個內(nèi)
存空間大小的設(shè)置，在NT上是3M，那么10萬并發(fā)就需要300G內(nèi)存，當(dāng)然實際使用中考慮其
他程序也占用內(nèi)存，所以準(zhǔn)備的內(nèi)存數(shù)量要求比這個還要多一些。還有10萬個用戶同時在
線，跟10萬個并發(fā)數(shù)是完全不同的2個概念。這個樓上已經(jīng)說了。但如何做這個轉(zhuǎn)換將10
萬個同時在線用戶轉(zhuǎn)換成多少個并發(fā)數(shù)呢？這就必須要有大量的歷史日志信息來支撐了。
系統(tǒng)日志需要有同時在線用戶數(shù)量的日志信息，還需要有用戶操作次數(shù)的日志信息，這2
個數(shù)據(jù)的比例就是你同時在線用戶轉(zhuǎn)換到并發(fā)數(shù)的比例。另外根據(jù)經(jīng)驗統(tǒng)計，對于1個
JAVA開發(fā)的WEB系統(tǒng)（別的我沒統(tǒng)計過，給不出數(shù)據(jù)），一般1臺雙CPU、2G內(nèi)存的服務(wù)器
上可支持的最大并發(fā)數(shù)不超過500個（這個狀態(tài)下大部分操作都是超時報錯而且服務(wù)器很
容易宕機(jī)，其實沒什么實際意義），可正常使用（單步非大數(shù)據(jù)量操作等待時間不超過20
秒）的最大并發(fā)數(shù)不超過300個。假設(shè)你的10萬同時在線用戶轉(zhuǎn)換的并發(fā)數(shù)是9000個，那
么你最少需要這樣的機(jī)器18臺，建議不少于30臺。當(dāng)然，你要是買個大型服務(wù)器，里面裝
有200個CPU、256G的內(nèi)存，千兆光纖帶寬，就算是10萬個并發(fā)用戶，那速度，也絕對是嗖
嗖的。
另外暴寒1下，光設(shè)置全部進(jìn)入運(yùn)行狀態(tài)就需要接近6個小時。具體的可以拿1個系統(tǒng)
來壓一下看看，可能會出現(xiàn)以下情況：
1、服務(wù)器宕機(jī)；
2、客戶端宕機(jī)；
3、從某個時間開始服務(wù)器拒絕請求，客戶端上顯示的全是錯誤；
4、勉強(qiáng)測試完成，但網(wǎng)絡(luò)堵塞或測試結(jié)果顯示時間非常長。假設(shè)客戶端和服務(wù)器之
間百兆帶寬，百兆/10000=10K，那每個用戶只能得到10K，這個速度接近1個64K的MODEM上
網(wǎng)的速度；另外以上分析全都沒考慮系統(tǒng)的后臺，比如數(shù)據(jù)庫、中間件等。
1、服務(wù)器方面：上面說的那樣的PC SERVER需要50臺；
2、網(wǎng)絡(luò)方面：按每個用戶50K，那至少5根百兆帶寬獨享，估計僅僅網(wǎng)絡(luò)延遲就大概
是秒一級的；
3、如果有數(shù)據(jù)庫，至少是ORACLE，最好是SYSBASE，SQLSERVER是肯定頂不住的。數(shù)
據(jù)庫服務(wù)器至少需要10臺4CPU、16G內(nèi)存的機(jī)器；
4、如果有CORBA，那至少再準(zhǔn)備10臺4CPU、16G內(nèi)存的機(jī)器；再加上負(fù)載均衡、防火
墻、路由器和各種軟件等，總之沒個1000萬的資金投入，肯定搞不定。
這樣的門戶系統(tǒng)，由于有用戶權(quán)限，所以并不象jackie所說大多是靜態(tài)頁面。但只要
是多服務(wù)器的集群，那么我們就可以通過1臺機(jī)器的測試結(jié)果來計算多臺機(jī)器集群后的負(fù)
載能力的，最多額外考慮一下負(fù)載均衡和路由上的壓力，比如帶寬、速度、延遲等。但如
果都是在1臺機(jī)器上變化，那我們只能做一些指標(biāo)上的計算，可以從這些指標(biāo)上簡單判斷
一下是否不可行，比如10萬并發(fā)用戶卻只有1根百兆帶寬，那我們可以計算出每個用戶只
有1K帶寬，這顯然是不可行的。但實際的結(jié)果還是需要測試了才知道，畢竟系統(tǒng)壓力和用
戶數(shù)量不是線性變化的。
這一類系統(tǒng)的普遍的成熟的使用，以及很多軟件在方案設(shè)計后就能夠大致估算出系統(tǒng)
的性能特點，都導(dǎo)致了系統(tǒng)在軟件性能方面調(diào)優(yōu)的比例并不大（當(dāng)然不完全排除后期針對
某些代碼和配置進(jìn)行優(yōu)化后性能的進(jìn)一步提高），更多的都是從硬件方面來考慮，比如增
加內(nèi)存、硬盤做RAID、增加帶寬、甚至增加機(jī)器等。
網(wǎng)絡(luò)技術(shù)中的10M 帶寬指的是以位計算， 就是 10M bit /秒 ，而下載時的速度看到
的是以字節(jié)（Byte）計算的，所以10M帶寬換算成字節(jié)理論上最快下載速度為： 1.25 M?
Byte/秒!
總結(jié)
- 上一篇： CSS弹出二级多列菜单和DIV布局实例
- 下一篇： w3cschool的jQuery Mob