web性能測試基本性能指標(biāo)_第1頁
web性能測試基本性能指標(biāo)_第2頁
web性能測試基本性能指標(biāo)_第3頁
web性能測試基本性能指標(biāo)_第4頁
免費預(yù)覽已結(jié)束,剩余1頁可下載查看

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報或認(rèn)領(lǐng)

文檔簡介

1、web性能測試基本性能指標(biāo)Web 性能測試的部分概況一般來說,一個 Web 請求的處理包括以下步驟:(1)客戶發(fā)送請求(2)webserver 接受到請求,進(jìn)行處理;(3)webserver 向 DB 獲取數(shù)據(jù);(4)webserver 生成用戶的 object(頁面), 返回給用戶。 給客戶發(fā)送請求開始到最后一個字節(jié)的時間稱為響應(yīng)時間(第三步不包括在每次請求處理中)。1 .事務(wù)(Transaction)在 web 性能測試中,一個事務(wù)表示一個從用戶發(fā)送請求-webserver 接受到請求,進(jìn)行處理-webserver 向 DB獲取數(shù)據(jù)-生成用戶的 object(頁面),返回給用戶”的過程,一

2、般的響應(yīng)時間都是針對事務(wù)而言的。2 .請求響應(yīng)時間請求響應(yīng)時間指的是從客戶端發(fā)起的一個請求開始,到客戶端接收到從服務(wù)器端返回的響應(yīng)結(jié)束,這個過程所耗費的時間,在某些工具中,響應(yīng)通常會稱為“TTLB;即timetolastbyte,意思是從發(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)在 35 秒鐘內(nèi),頁面給予用戶響應(yīng)并有所顯示,可認(rèn)為是“好的”;(3)在 510 秒

3、鐘內(nèi),頁面給予用戶響應(yīng)并有所顯示,可認(rèn)為是“勉強接受的”;(4)超過 10 秒就讓人有點不耐煩了,用戶很可能不會繼續(xù)等待下去;2 、事務(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)

4、行完全一樣的操作,例如在信用卡審批業(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ā)生在使用比

5、較頻繁的模塊中,盡管發(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 .吞吐量指的是在一次性能測

6、試過程中網(wǎng)絡(luò)上傳輸?shù)臄?shù)據(jù)量的總和.吞吐量/傳輸時間,就是吞吐率.6 、TPS(transactionpersecond)每秒鐘系統(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)生的影響。需要注意的是,這里的點擊并

7、非指鼠標(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ù)就接近飽和MemoryAvaila

8、bleMbyte可用內(nèi)存數(shù),如果測試時發(fā)現(xiàn)內(nèi)存有變化情況也要注意,如果是內(nèi)存泄露則比較嚴(yán)重PhysicsdiskTime物理磁盤讀寫時間情況Web 服務(wù)器指標(biāo)指標(biāo)說明RequestsPerSecond(AvgRps)平均每秒鐘響應(yīng)次數(shù)=總請求時間/秒數(shù)Avgtimetolastbyteperterstion(mstes)平均每秒業(yè)務(wù)腳本的迭代次數(shù),有人會把上面那個混淆SuccessfulRounds成功的請求FailedRequests失敗的請求SuccessfulHits成功的點擊次數(shù)FailedHitsHitsPerSecond失敗的點擊次數(shù)每秒點擊次數(shù)SuccessfulHitsPerS

9、econd每秒成功的點擊次數(shù)FailedHitsPerSecond每秒失敗的點擊次數(shù)AttemptedConnections嘗試鏈接數(shù)數(shù)據(jù)庫服務(wù)器性能指標(biāo)指標(biāo)說明User0Connections用戶連接數(shù),也就是數(shù)據(jù)庫的連接數(shù)量Numberofdeadlocks數(shù)據(jù)庫死鎖ButterCachehit數(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)分頁空

10、間的活動率超過 70%寸換頁限制ostat,stat虛存邏輯卷%tm_act超過 I/O(iostat)的 30%,激活的虛存率超過CPUB 量(vmstat)的 10 倍時系統(tǒng)失效Vmstat,sar頁交換增大、CPU 等待并運行隊列穩(wěn)定系統(tǒng)的資源狀態(tài)性能項資源評價CPU 占用率70%好85%壞90%+很差磁盤 I/030%好40%壞50%+很差網(wǎng)絡(luò)30%f 寬好運行隊列2*CPU 數(shù)量好內(nèi)存殳有頁交換好每個 CPU秒 10 個頁交換壞年多的頁交換很差通俗理解:日訪問量常用頁面最大并發(fā)數(shù)同時在線人數(shù)訪問相應(yīng)時間案例:最近公司一個項目,是個門戶網(wǎng)站,需要做性能測試,根據(jù)項目特點定出了主要測試項

11、和測試方案:一種是測試幾個常用頁面能接受的最大并發(fā)數(shù)(用戶名參數(shù)化,設(shè)置集合點策略)一種是測試服務(wù)器長時間壓力下,用戶能否正常操作(用戶名參數(shù)化,迭代運行腳本)一種則需要測試服務(wù)器能否接受 10 萬用戶同時在線操作,如果是用 IIS 做應(yīng)用服務(wù)器的話,單臺可承受的最大并發(fā)數(shù)不可能達(dá)到 10 萬級,那就必須要使用集群,通過多臺機器做負(fù)載均衡來實現(xiàn);如果是用 websphere 之類的應(yīng)用服務(wù)器的話,單臺可承受的最大并發(fā)數(shù)可以達(dá)到 10 萬級,但為性能考慮還是必須要使用集群, 通過多臺機器做負(fù)載均衡來實現(xiàn); 通常有 1 個簡單的計算方式, 1 個連接產(chǎn)生 1 個 session,每個 sessio

12、n在服務(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)計過,給不出

13、數(shù)據(jù)),一般 1 臺雙 CPU、2G 內(nèi)存的服務(wù)器上可支持的最大并發(fā)數(shù)不超過 500 個(這個狀態(tài)下大部分操作都是超時報錯而且服務(wù)器很容易宕機,其實沒什么實際意義),可正常使用(單步非大數(shù)據(jù)量操作等待時間不超過20 秒)的最大并發(fā)數(shù)不超過 300 個。假設(shè)你的 10 萬同時在線用戶轉(zhuǎn)換的并發(fā)數(shù)是 9000 個,那么你最少需要這樣的機器 18 臺,建議不少于 30 臺。當(dāng)然,你要是買個大型服務(wù)器,里面裝有 200 個 CPU、256G 的內(nèi)存,千兆光纖帶寬,就算是 10 萬個并發(fā)用戶,那速度,也絕對是嗖嗖的。另外暴寒 1 下,光設(shè)置全部進(jìn)入運行狀態(tài)就需要接近 6 個小時。具體的可以拿 1 個系統(tǒng)

14、來壓一下看看,可能會出現(xiàn)以下情況:1、服務(wù)器宕機;2、客戶端宕機;3、從某個時間開始服務(wù)器拒絕請求,客戶端上顯示的全是錯誤;4、 勉強測試完成, 但網(wǎng)絡(luò)堵塞或測試結(jié)果顯示時間非常長。 假設(shè)客戶端和服務(wù)器之間百兆帶寬, 百兆/10000=10K,那每個用戶只能得到 10K,這個速度接近 1 個 64K 的 MODEM 上網(wǎng)的速度;另外以上分析全都沒考慮系統(tǒng)的后臺,比如數(shù)據(jù)庫、中間件等。1、服務(wù)器方面:上面說的那樣的 PCSERVER 需要 50 臺;2、網(wǎng)絡(luò)方面:按每個用戶 50K,那至少 5 根百兆帶寬獨享,估計僅僅網(wǎng)絡(luò)延遲就大概是秒一級的;3、如果有數(shù)據(jù)庫,至少是 ORACLE,最好是 SY

15、SBASE,SQLSERVER 是肯定頂不住的。數(shù)據(jù)庫服務(wù)器至少需要10 臺 4CPU、16G 內(nèi)存的機器;14、如果有 CORBA,那至少再準(zhǔn)備 10 臺 4CPU、16G 內(nèi)存的機器;再加上負(fù)載均衡、防火墻、路由器和各種軟件等,總之沒個 1000 萬的資金投入,肯定搞不定。這樣的門戶系統(tǒng),由于有用戶權(quán)限,所以并不象 jackie 所說大多是靜態(tài)頁面。但只要是多服務(wù)器的集群,那么我們就可以通過 1 臺機器的測試結(jié)果來計算多臺機器集群后的負(fù)載能力的,最多額外考慮一下負(fù)載均衡和路由上的壓力,比如帶寬、速度、延遲等。但如果都是在 1 臺機器上變化,那我們只能做一些指|標(biāo)上的計算,可以從這些指標(biāo)上簡單判斷一下是否不可行,比如 10 萬并發(fā)用戶卻只有 1 根百兆帶寬,那我們可以計算出每個用戶只有 1K 帶寬,這顯然是不可行的。但實際的結(jié)果還是需要測試了才知道,畢竟系統(tǒng)壓力和用戶數(shù)量不是

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論