posts - 97,  comments - 5,  trackbacks - 0
          @import url(http://www.aygfsteel.com/CuteSoft_Client/CuteEditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css);

          LoadRunner沒(méi)有告訴你的》 《轉(zhuǎn)載》

          1.        LoadRunner—Block

          l  如何在一個(gè)腳本中實(shí)現(xiàn)不同事務(wù)不同次數(shù)的循環(huán)呢?

          l  案例:假如你想在一個(gè)腳本中,實(shí)現(xiàn)登錄執(zhí)行1次,查詢執(zhí)行2次,插入執(zhí)行3次,怎么辦?錄3個(gè)腳本?每個(gè)事務(wù)分別在腳本中復(fù)制N次?

          l  當(dāng)然不用,LR早就想到了你的需求,下面讓我們隆重推出Block

          l  位置:Run-time Settings--General--Run Logic

          l  操作:

          l  將你所要考察的事務(wù)設(shè)置在不同的Action內(nèi)。

          l  Run Logic中的Run中刪掉默認(rèn)的Action

          l  Run中插入Block

          l  在插入的Block中再插入我們要考察的Action

          l  設(shè)置Blockproperties。這里有兩種選擇,SequentialRandom。如果選擇Sequential,在下面的Iteration中直接填入數(shù)值,那么Block中的Action都會(huì)按輸入的次數(shù)執(zhí)行。如果選擇Random,下面的properties還可以設(shè)置Block內(nèi)各Action執(zhí)行的百分比。

          l  按照我們前面的案例,我們只需要設(shè)置3個(gè)Block,每個(gè)Block中分別插入一個(gè)Action,設(shè)置執(zhí)行次數(shù)分別為123就可以了。

           

          l  本人理解補(bǔ)充

          1、  如果腳本中各個(gè)action沒(méi)有順序或邏輯關(guān)系,Blockaction順序可以是任意的。如查詢。但是像登錄這樣必須在前面執(zhí)行的action,隨意放置將導(dǎo)致腳本失敗。

          2、  Number of Iterations中設(shè)置的循環(huán)次數(shù),作用于Run(x)下的所有Action,而不作用于Block下的action。即Block下的action可以通過(guò)設(shè)置BlockProperties來(lái)指定循環(huán)的次數(shù)。

          2.        LoadRunner 沒(méi)有告訴你的》之一——描述性統(tǒng)計(jì)與性能結(jié)果分析

          l  LoadRunner中的90%響應(yīng)時(shí)間是什么意思?這個(gè)值在進(jìn)行性能分析時(shí)有什么作用?本文爭(zhēng)取用最簡(jiǎn)潔的文字來(lái)解答這個(gè)問(wèn)題,并引申出“描述性統(tǒng)計(jì)”方法在性能測(cè)試結(jié)果分析中的應(yīng)用。

          l  為什么要有90%用戶響應(yīng)時(shí)間?因?yàn)樵谠u(píng)估一次測(cè)試的結(jié)果時(shí),僅僅有平均事務(wù)響應(yīng)時(shí)間是不夠的。為什么這么說(shuō)?你可以試著想想,是否平均事務(wù)響應(yīng)時(shí)間滿足了性能需求就表示系統(tǒng)的性能已經(jīng)滿足了絕大多數(shù)用戶的要求?

          l  假如有兩組測(cè)試結(jié)果,響應(yīng)時(shí)間分別是 {1351016} {56789},它們的平均值都是7,你認(rèn)為哪次測(cè)試的結(jié)果更理想?

          l  假如有一次測(cè)試,總共有100個(gè)請(qǐng)求被響應(yīng),其中最小響應(yīng)時(shí)間為0.02秒,最大響應(yīng)時(shí)間為110秒,平均事務(wù)響應(yīng)時(shí)間為4.7秒,你會(huì)不會(huì)想到最小和最大響應(yīng)時(shí)間如此大的偏差是否會(huì)導(dǎo)致平均值本身并不可信?

          l  為了解答上面的疑問(wèn),我們先來(lái)看一張表:

          l  在上面這個(gè)表中包含了幾個(gè)不同的列,其含義如下:

          l  CmdID   測(cè)試時(shí)被請(qǐng)求的頁(yè)面

          l  NUM      響應(yīng)成功的請(qǐng)求數(shù)量

          l  MEAN    所有成功的請(qǐng)求的響應(yīng)時(shí)間的平均值

          l  STD DEV      標(biāo)準(zhǔn)差(這個(gè)值的作用將在下一篇文章中重點(diǎn)介紹)

          l  MIN              響應(yīng)時(shí)間的最小值

          l  50 th(60/70/80/90/95 th)          如果把響應(yīng)時(shí)間從小到大順序排序,那么50%的請(qǐng)求的響應(yīng)時(shí)間在這個(gè)范圍之內(nèi)。后面的60/70/80/90/95 th 也是同樣的含義

          l  MAX      響應(yīng)時(shí)間的最大值

          l  我想看完了上面的這個(gè)表和各列的解釋,不用多說(shuō)大家也可以明白我的意思了。我把結(jié)論性的東西整理一下:

          l  1.      90%用戶響應(yīng)時(shí)間在 LoadRunner中是可以設(shè)置的,你可以改為80%或95%;

          l  2.      對(duì)于這個(gè)表,LoadRunner中是沒(méi)有直接提供的,你可以把LR中的原始數(shù)據(jù)導(dǎo)出到Excel中,并使用Excel中的PERCENTILE 函數(shù)很簡(jiǎn)單的算出不同百分比用戶請(qǐng)求的響應(yīng)時(shí)間分布情況;

          l  3.      從上面的表中來(lái)看,對(duì)于Home Page來(lái)說(shuō),平均事務(wù)響應(yīng)時(shí)間(MEAN)只同70%用戶響應(yīng)時(shí)間相一致。也就是說(shuō)假如我們確定Home Page的響應(yīng)時(shí)間應(yīng)該在5秒內(nèi),那么從平均事務(wù)響應(yīng)時(shí)間來(lái)看是滿足的,但是實(shí)際上有10-20%的用戶請(qǐng)求的響應(yīng)時(shí)間是大于這個(gè)值的;對(duì)于Page 1也是一樣,假如我們確定對(duì)于Page 1 的請(qǐng)求應(yīng)該在3秒內(nèi)得到響應(yīng),雖然平均事務(wù)響應(yīng)時(shí)間是滿足要求的,但是實(shí)際上有20-30%的用戶請(qǐng)求的響應(yīng)時(shí)間是超過(guò)了我們的要求的;

          l  4.      你可以在95 th之后繼續(xù)添加96/ 97/ 98/ 99/ 99.9/ 99.99 th,并利用Excel的圖表功能畫(huà)一條曲線,來(lái)更加清晰表現(xiàn)出系統(tǒng)響應(yīng)時(shí)間的分布情況。這時(shí)候你也許會(huì)發(fā)現(xiàn),那個(gè)最大值的出現(xiàn)幾率只不過(guò)是千分之一甚至萬(wàn)分之一,而且99%的用戶請(qǐng)求的響應(yīng)時(shí)間都是在性能需求所定義的范圍之內(nèi)的;

          l  5.      如果你想使用這種方法來(lái)評(píng)估系統(tǒng)的性能,一個(gè)推薦的做法是盡可能讓你的測(cè)試場(chǎng)景運(yùn)行的時(shí)間長(zhǎng)一些,因?yàn)楫?dāng)你獲得的測(cè)試數(shù)據(jù)越多,這個(gè)響應(yīng)時(shí)間的分布曲線就越接近真實(shí)情況;

          l  6.      在確定性能需求時(shí),你可以用平均事務(wù)響應(yīng)時(shí)間來(lái)衡量系統(tǒng)的性能,也可以用90%或95%用戶響應(yīng)時(shí)間來(lái)作為度量標(biāo)準(zhǔn),它們并不沖突。實(shí)際上,在定義某些系統(tǒng)的性能需求時(shí),一定范圍內(nèi)的請(qǐng)求失敗也是可以被接受的;

          l  7.      上面提到的這些內(nèi)容其實(shí)是與工具無(wú)關(guān)的,只要你可以得到原始的響應(yīng)時(shí)間記錄,無(wú)論是使用LoadRunner還是JMeter或者OpenSTA,你都可以用這些方法和思路來(lái)評(píng)估你的系統(tǒng)的性能。

          l  事實(shí)上,在性能測(cè)試領(lǐng)域中還有更多的東西是目前的商業(yè)測(cè)試工具或者開(kāi)源測(cè)試工具都沒(méi)有專門講述的——換句話說(shuō),性能測(cè)試僅僅有工具是不夠的。我們還需要更多其他領(lǐng)域的知識(shí),例如數(shù)學(xué)和統(tǒng)計(jì)學(xué),來(lái)幫助我們更好的分析性能數(shù)據(jù),找到隱藏在那些數(shù)據(jù)之下的真相。

          3.        LoadRunner 沒(méi)有告訴你的》之二——描述性統(tǒng)計(jì)與性能結(jié)果分析

          l      數(shù)據(jù)統(tǒng)計(jì)分析的思路與分析結(jié)果的展示方式是同樣重要的,有了好的分析思路,但是卻不懂得如何更好的展示分析結(jié)果和數(shù)據(jù)來(lái)印證自己的分析,就像一個(gè)人滿腹經(jīng)綸卻不知該如何一展雄才 ^_^

          l  一圖勝千言,所以這次我會(huì)用兩張圖表來(lái)說(shuō)明“描述性統(tǒng)計(jì)”在性能測(cè)試結(jié)果分析中的其他應(yīng)用。

          l 

          l  在這張圖中,我們繼續(xù)使用了上一篇文章——《描述性統(tǒng)計(jì)與結(jié)果分析》一文中的方法,對(duì)響應(yīng)時(shí)間的分布情況來(lái)進(jìn)行分析。上面這張圖所使用的數(shù)據(jù)是通過(guò)對(duì)

          l  Google.com 首頁(yè)進(jìn)行測(cè)試得來(lái)的,在測(cè)試中分別使用10/25/50/75/100 幾個(gè)不同級(jí)別的并發(fā)用戶數(shù)量。通過(guò)這張圖表,我們可以通過(guò)橫向比較和縱向比較,更清晰的了解到被測(cè)應(yīng)用在不同級(jí)別的負(fù)載下的響應(yīng)能力。

          l 

          l  這張圖所使用的數(shù)據(jù)與第一張圖一樣,但是我們使用了另外一個(gè)視角來(lái)對(duì)數(shù)據(jù)進(jìn)行展示。表中最左側(cè)的2000/5000/10000/50000的單位是毫秒,分別表示了在整個(gè)測(cè)試過(guò)程中,響應(yīng)時(shí)間在0-2000毫秒范圍內(nèi)的事務(wù)數(shù)量占成功的事務(wù)總數(shù)的百分比,響應(yīng)時(shí)間在2001-5000毫秒范圍內(nèi)的事務(wù)數(shù)量占成功的事務(wù)總數(shù)的百分比,響應(yīng)時(shí)間在5001-10000毫秒范圍內(nèi)的事務(wù)數(shù)量占成功的事務(wù)總數(shù)的百分比,以及響應(yīng)時(shí)間在10001-50000毫秒范圍內(nèi)的事務(wù)數(shù)量占成功的事務(wù)總數(shù)的百分比。

          l  這幾個(gè)時(shí)間范圍的確定是參考了業(yè)內(nèi)比較通行的“2-5-10原則”——當(dāng)然你也可以為自己的測(cè)試制定其他標(biāo)準(zhǔn),只要得到企業(yè)內(nèi)的承認(rèn)就可以。所謂的“2-5-10原則”,簡(jiǎn)單說(shuō),就是當(dāng)用戶能夠在2秒以內(nèi)得到響應(yīng)時(shí),會(huì)感覺(jué)系統(tǒng)的響應(yīng)很快;當(dāng)用戶在2-5秒之間得到響應(yīng)時(shí),會(huì)感覺(jué)系統(tǒng)的響應(yīng)速度還可以;當(dāng)用戶在5-10秒以內(nèi)得到響應(yīng)時(shí),會(huì)感覺(jué)系統(tǒng)的響應(yīng)速度很慢,但是還可以接受;而當(dāng)用戶在超過(guò)10秒后仍然無(wú)法得到響應(yīng)時(shí),會(huì)感覺(jué)系統(tǒng)糟透了,或者認(rèn)為系統(tǒng)已經(jīng)失去響應(yīng),而選擇離開(kāi)這個(gè)Web站點(diǎn),或者發(fā)起第二次請(qǐng)求。

          l  那么從上面的圖表中可以看到,當(dāng)并發(fā)用戶數(shù)量為10時(shí),超過(guò)95%的用戶都可以在5秒內(nèi)得到響應(yīng);當(dāng)并發(fā)用戶數(shù)量達(dá)到25時(shí),已經(jīng)有80%的事務(wù)的響應(yīng)時(shí)間處在危險(xiǎn)的臨界值,而且有相當(dāng)數(shù)量的事務(wù)的響應(yīng)時(shí)間超過(guò)了用戶可以容忍的限度;隨著并發(fā)用戶數(shù)量的進(jìn)一步增加,超過(guò)用戶容忍限度的事務(wù)越來(lái)越多,當(dāng)并發(fā)用戶數(shù)到達(dá)75時(shí),系統(tǒng)幾乎已經(jīng)無(wú)法為任何用戶提供響應(yīng)了。

          l  這張圖表也同樣可以用于對(duì)不同負(fù)載下事務(wù)的成功、失敗比例的比較分析。

          l  Note:上面兩個(gè)圖表中的數(shù)據(jù),主要通過(guò)Excel 中提供的FREQUENCYAVERAGEMAXMINPERCENTILE幾個(gè)統(tǒng)計(jì)函數(shù)獲得,具體的使用方法請(qǐng)參考Excel幫助手冊(cè)。

          4.        LoadRunner 沒(méi)有告訴你的》之三——理發(fā)店模型

          l  相信大家都進(jìn)過(guò)或見(jiàn)過(guò)理發(fā)店,一間或大或小的鋪面,1個(gè)或幾個(gè)理發(fā)師,幾張理發(fā)用的椅子和供顧客等待的長(zhǎng)條板凳

          l 

          l  在我們的這個(gè)理發(fā)店中,我們事先做了如下的假設(shè):

          l  1.       理發(fā)店共有3名理發(fā)師;

          l  2.      每位理發(fā)師剪一個(gè)發(fā)的時(shí)間都是1小時(shí);

          l  3.      我們顧客們都是很有時(shí)間觀念的人而且非常挑剔,他們對(duì)于每次光顧理發(fā)店時(shí)所能容忍的等待時(shí)間+剪發(fā)時(shí)間是3小時(shí),而且等待時(shí)間越長(zhǎng),顧客的滿意度越低。如果3個(gè)小時(shí)還不能剪完頭發(fā),我們的顧客會(huì)立馬生氣的走人。

          l  通過(guò)上面的假設(shè)我們不難想象出下面的場(chǎng)景:

          l  1.  當(dāng)理發(fā)店內(nèi)只有1位顧客時(shí),只需要有1名理發(fā)師為他提供服務(wù),其他兩名理發(fā)師可能繼續(xù)等著,也可能會(huì)幫忙打打雜。1小時(shí)后,這位顧客剪完頭發(fā)出門走了。那么在這1個(gè)小時(shí)里,整個(gè)理發(fā)店只服務(wù)了1位顧客,這位顧客花費(fèi)在這次剪發(fā)的時(shí)間是1小時(shí);

          l  2.  當(dāng)理發(fā)店內(nèi)同時(shí)有兩位顧客時(shí),就會(huì)同時(shí)有兩名理發(fā)師在為顧客服務(wù),另外1位發(fā)呆或者打雜幫忙。仍然是1小時(shí)后,兩位顧客剪完頭發(fā)出門。在這1小時(shí)里,理發(fā)店服務(wù)了兩位顧客,這兩位顧客花費(fèi)在剪發(fā)的時(shí)間均為1小時(shí);

          l  3.  很容易理解,當(dāng)理發(fā)店內(nèi)同時(shí)有三位顧客時(shí),理發(fā)店可以在1小時(shí)內(nèi)同時(shí)服務(wù)三位顧客,每位顧客花費(fèi)在這次剪發(fā)的時(shí)間仍然是均為1小時(shí);

          l  從上面幾個(gè)場(chǎng)景中我們可以發(fā)現(xiàn),在理發(fā)店同時(shí)服務(wù)的顧客數(shù)量從1位增加到3位的過(guò)程中,隨著顧客數(shù)量的增多,理發(fā)店的整體工作效率在提高,但是每位顧客在理發(fā)店內(nèi)所呆的時(shí)間并未延長(zhǎng)。

          l  當(dāng)然,我們可以假設(shè)當(dāng)只有1位顧客和2位顧客時(shí),空閑的理發(fā)師可以幫忙打雜,使得其他理發(fā)師的工作效率提高,并使每位顧客的剪發(fā)時(shí)間小于1小時(shí)。不過(guò)即使根據(jù)這個(gè)假設(shè),雖然隨著顧客數(shù)量的增多,每位顧客的服務(wù)時(shí)間有所延長(zhǎng),但是這個(gè)時(shí)間始終還被控制在顧客可接受的范圍之內(nèi),并且顧客是不需要等待的。

          l  不過(guò)隨著理發(fā)店的生意越來(lái)越好,顧客也越來(lái)越多,新的場(chǎng)景出現(xiàn)了。假設(shè)有一次顧客ABC剛進(jìn)理發(fā)店準(zhǔn)備剪發(fā),外面一推門又進(jìn)來(lái)了顧客DEF。因?yàn)?/span>ABC三位顧客先到,所以DEF三位只好坐在長(zhǎng)板凳上等著。1小時(shí)后,ABC三位剪完頭發(fā)走了,他們每個(gè)人這次剪發(fā)所花費(fèi)的時(shí)間均為1小時(shí)。可是DEF三位就沒(méi)有這么好運(yùn),因?yàn)樗麄円鹊?/span>ABC三位剪完才能剪,所以他們每個(gè)人這次剪發(fā)所花費(fèi)的時(shí)間均為2小時(shí)——包括等待1小時(shí)和剪發(fā)1小時(shí)。

          l  通過(guò)上面這個(gè)場(chǎng)景我們可以發(fā)現(xiàn),對(duì)于理發(fā)店來(lái)說(shuō),都是每小時(shí)服務(wù)三位顧客——第1個(gè)小時(shí)是ABC,第二個(gè)小時(shí)是DEF;但是對(duì)于顧客DEF來(lái)說(shuō),“響應(yīng)時(shí)間”延長(zhǎng)了。如果你可以理解上面的這些場(chǎng)景,就可以繼續(xù)往下看了。

          l  在新的場(chǎng)景中,我們假設(shè)這次理發(fā)店里一次來(lái)了9位顧客,根據(jù)我們上面的場(chǎng)景,相信你不難推斷,這9位顧客中有3位的“響應(yīng)時(shí)間”為1小時(shí),有3位的“響應(yīng)時(shí)間”為2小時(shí)(等待1小時(shí)+剪發(fā)1小時(shí)),還有3位的“響應(yīng)時(shí)間”為3小時(shí)(等待2小時(shí)+剪發(fā)1小時(shí))——已經(jīng)到達(dá)用戶所能忍受的極限。假如在把這個(gè)場(chǎng)景中的顧客數(shù)量改為10,那么我們已經(jīng)可以斷定,一定會(huì)有1位顧客因?yàn)?#8220;響應(yīng)時(shí)間”過(guò)長(zhǎng)而無(wú)法忍受,最終離開(kāi)理發(fā)店走了。

          l  我想并不需要特別說(shuō)明,大家也一定可以把上面的這些場(chǎng)景跟性能測(cè)試掛上鉤了。如果你還是覺(jué)得比較抽象,繼續(xù)看下面的這張圖 ^_^

          l 

          l  這張圖中展示的是1個(gè)標(biāo)準(zhǔn)的軟件性能模型。在圖中有三條曲線,分別表示資源的利用情況(Utilization,包括硬件資源和軟件資源)、吞吐量(Throughput,這里是指每秒事務(wù)數(shù))以及響應(yīng)時(shí)間(Response Time)。圖中坐標(biāo)軸的橫軸從左到右表現(xiàn)了并發(fā)用戶數(shù)(Number of Concurrent Users)的不斷增長(zhǎng)。

          l  在這張圖中我們可以看到,最開(kāi)始,隨著并發(fā)用戶數(shù)的增長(zhǎng),資源占用率和吞吐量會(huì)相應(yīng)的增長(zhǎng),但是響應(yīng)時(shí)間的變化不大;不過(guò)當(dāng)并發(fā)用戶數(shù)增長(zhǎng)到一定程度后,資源占用達(dá)到飽和,吞吐量增長(zhǎng)明顯放緩甚至停止增長(zhǎng),而響應(yīng)時(shí)間卻進(jìn)一步延長(zhǎng)。如果并發(fā)用戶數(shù)繼續(xù)增長(zhǎng),你會(huì)發(fā)現(xiàn)軟硬件資源占用繼續(xù)維持在飽和狀態(tài),但是吞吐量開(kāi)始下降,響應(yīng)時(shí)間明顯的超出了用戶可接受的范圍,并且最終導(dǎo)致用戶放棄了這次請(qǐng)求甚至離開(kāi)。

          l  根據(jù)這種性能表現(xiàn),圖中劃分了三個(gè)區(qū)域,分別是Light Load(較輕的壓力)、Heavy Load(較重的壓力)和Buckle Zone(用戶無(wú)法忍受并放棄請(qǐng)求)。在Light LoadHeavy Load 兩個(gè)區(qū)域交界處的并發(fā)用戶數(shù),我們稱為“最佳并發(fā)用戶數(shù)(The Optimum Number of Concurrent Users)”,而Heavy LoadBuckle Zone兩個(gè)區(qū)域交界處的并發(fā)用戶數(shù)則稱為“最大并發(fā)用戶數(shù)(The Maximum Number of Concurrent Users)”。

          l  當(dāng)系統(tǒng)的負(fù)載等于最佳并發(fā)用戶數(shù)時(shí),系統(tǒng)的整體效率最高,沒(méi)有資源被浪費(fèi),用戶也不需要等待;當(dāng)系統(tǒng)負(fù)載處于最佳并發(fā)用戶數(shù)和最大并發(fā)用戶數(shù)之間時(shí),系統(tǒng)可以繼續(xù)工作,但是用戶的等待時(shí)間延長(zhǎng),滿意度開(kāi)始降低,并且如果負(fù)載一直持續(xù),將最終會(huì)導(dǎo)致有些用戶無(wú)法忍受而放棄;而當(dāng)系統(tǒng)負(fù)載大于最大并發(fā)用戶數(shù)時(shí),將注定會(huì)導(dǎo)致某些用戶無(wú)法忍受超長(zhǎng)的響應(yīng)時(shí)間而放棄。

          l  對(duì)應(yīng)到我們上面理發(fā)店的例子,每小時(shí)3個(gè)顧客就是這個(gè)理發(fā)店的最佳并發(fā)用戶數(shù),而每小時(shí)9個(gè)顧客則是它的最大并發(fā)用戶數(shù)。當(dāng)每小時(shí)都有3個(gè)顧客到來(lái)時(shí),理發(fā)店的整體工作效率最高;而當(dāng)每小時(shí)都有9個(gè)顧客到來(lái)時(shí),前幾個(gè)小時(shí)來(lái)的顧客還可以忍受,但是隨著等待的顧客人數(shù)越來(lái)越多,等待時(shí)間越來(lái)越長(zhǎng),最終還是會(huì)有顧客無(wú)法忍受而離開(kāi)。同時(shí),隨著理發(fā)店里顧客人數(shù)的增多和理發(fā)師工作時(shí)間的延長(zhǎng),理發(fā)師會(huì)逐漸產(chǎn)生疲勞,還要多花一些時(shí)間來(lái)清理環(huán)境和維持秩序,這些因素將最終導(dǎo)致理發(fā)師的工作效率隨著顧客人數(shù)的增多和工作的延長(zhǎng)而逐漸的下降,到最后可能要1.5小時(shí)甚至2個(gè)小時(shí)才能剪完1個(gè)發(fā)了。

          l  當(dāng)然,如果一開(kāi)始就有10個(gè)顧客到來(lái),則注定有1位顧客剪不到頭發(fā)了。

           

          l  進(jìn)一步理解“最佳并發(fā)用戶數(shù)”和“最大并發(fā)用戶數(shù)”

          l  在上一節(jié)中,我們?cè)敿?xì)的描述了并發(fā)用戶數(shù)同資源占用情況、吞吐量以及響應(yīng)時(shí)間的關(guān)系,并且提到了兩個(gè)新的概念——“最佳并發(fā)用戶數(shù)(The Optimum Number of Concurrent Users)”和“最大并發(fā)用戶數(shù)(The Maximum Number of Concurrent Users)”。在這一節(jié)中,我們將對(duì)“最佳并發(fā)用戶數(shù)”和“最大并發(fā)用戶數(shù)”的定義做更加清晰和明確的說(shuō)明。

          l  對(duì)于一個(gè)確定的被測(cè)系統(tǒng)來(lái)說(shuō),在某個(gè)具體的軟硬件環(huán)境下,它的“最佳并發(fā)用戶數(shù)”和“最大并發(fā)用戶數(shù)”都是客觀存在。以“最佳并發(fā)用戶數(shù)”為例,假如一個(gè)系統(tǒng)的最佳并發(fā)用戶數(shù)是50,那么一旦并發(fā)量超過(guò)這個(gè)值,系統(tǒng)的吞吐量和響應(yīng)時(shí)間必然會(huì) “此消彼長(zhǎng)”;如果系統(tǒng)負(fù)載長(zhǎng)期大于這個(gè)數(shù),必然會(huì)導(dǎo)致用戶的滿意度降低并最終達(dá)到一種無(wú)法忍受的地步。所以我們應(yīng)該 保證最佳并發(fā)用戶數(shù)要大于系統(tǒng)的平均負(fù)載。

          l  要補(bǔ)充的一點(diǎn)是,當(dāng)我們需要對(duì)一個(gè)系統(tǒng)長(zhǎng)時(shí)間施加壓力——例如連續(xù)加壓3-5天,來(lái)驗(yàn)證系統(tǒng)的可靠性或者說(shuō)穩(wěn)定性時(shí),我們所使用的并發(fā)用戶數(shù)應(yīng)該等于或小于“最佳并發(fā)用戶數(shù)”——大家也可以結(jié)合上面的討論想想這是為什么 ^_^

          l  而對(duì)于最大并發(fā)用戶數(shù)的識(shí)別,需要考慮和鑒別一下以下兩種情況:

          l  1.              當(dāng)系統(tǒng)的負(fù)載達(dá)到最大并發(fā)用戶數(shù)后,響應(yīng)時(shí)間超過(guò)了用戶可以忍受的最大限度——這個(gè)限度應(yīng)該來(lái)源于性能需求,例如:在某個(gè)級(jí)別的負(fù)載下,系統(tǒng)的響應(yīng)時(shí)間應(yīng)該小于5秒。這里容易疏忽的一點(diǎn)是,不要把顧客因?yàn)闊o(wú)法忍受而離開(kāi)時(shí)店內(nèi)的顧客數(shù)量作為理發(fā)店的“最大并發(fā)用戶數(shù)”,因?yàn)檫@位顧客是在3小時(shí)前到達(dá)的,也就是說(shuō)3小時(shí)前理發(fā)店內(nèi)的顧客數(shù)量才是我們要找的“最大并發(fā)用戶數(shù)”。而且,這位顧客的離開(kāi)只是一個(gè)開(kāi)始,可能有會(huì)更多的顧客隨后也因?yàn)闊o(wú)法忍受超長(zhǎng)的等待時(shí)間而離開(kāi);

          l  2.             在響應(yīng)時(shí)間還沒(méi)有到達(dá)用戶可忍受的最大限度前,有可能已經(jīng)出現(xiàn)了用戶請(qǐng)求的失敗。以理發(fā)店模型為例,如果理發(fā)店只能容納6位顧客,那么當(dāng)7位顧客同時(shí)來(lái)到理發(fā)店時(shí),雖然我們可以知道所有顧客都能在可容忍的時(shí)間內(nèi)剪完頭發(fā),但是因?yàn)槔戆l(fā)店容量有限,最終只好有一位顧客打道回府,改天再來(lái)。

          l  對(duì)于一個(gè)系統(tǒng)來(lái)說(shuō),我們應(yīng)該 確保系統(tǒng)的最大并發(fā)用戶數(shù)要大于系統(tǒng)需要承受的峰值負(fù)載。

          l  如果你已經(jīng)理解了上面提到的全部的概念,我想你可以展開(kāi)進(jìn)一步的思考,回頭看一下自己以往做過(guò)的性能測(cè)試,看看是否可以對(duì)以往的工作產(chǎn)生新的理解。也歡迎大家在這里提出自己的心得或疑惑,繼續(xù)討論下去。

          l  理發(fā)店模型的進(jìn)一步擴(kuò)展

          l  這一節(jié)中我會(huì)提到一些對(duì)理發(fā)店模型的擴(kuò)展,當(dāng)然,我依然是只講述現(xiàn)實(shí)中的理發(fā)店的故事,至于如何將這些擴(kuò)展同性能測(cè)試以及性能解決方案等方面關(guān)聯(lián)起來(lái),就留給大家繼續(xù)思考了 ^_^

          l  擴(kuò)展場(chǎng)景1:有些顧客已經(jīng)是理發(fā)店的老顧客,他們和理發(fā)師已經(jīng)非常熟悉,理發(fā)師可以不用花費(fèi)太多時(shí)間溝通就知道這位顧客的想法。并且理發(fā)師對(duì)這位顧客的腦袋的形狀也很熟悉,所以可以更快的完成一次理發(fā)的工作。

          l  擴(kuò)展場(chǎng)景2:理發(fā)店并不是只有剪發(fā)一種業(yè)務(wù),還提供了燙發(fā)染發(fā)之類的業(yè)務(wù),那么當(dāng)顧客提出新的要求時(shí),理發(fā)師服務(wù)一位顧客的時(shí)間可能會(huì)超過(guò)標(biāo)準(zhǔn)的1小時(shí)。而且這時(shí)如果要計(jì)算每位顧客的等待時(shí)間就變得復(fù)雜了很多,有些顧客的排隊(duì)時(shí)間會(huì)比原來(lái)預(yù)計(jì)的延長(zhǎng),并最終導(dǎo)致他們因?yàn)闊o(wú)法忍受而離開(kāi)。

          l  擴(kuò)展場(chǎng)景3:隨著燙發(fā)和染發(fā)業(yè)務(wù)的增加,理發(fā)師們決定分工,兩位專門剪發(fā),一位專門負(fù)責(zé)燙發(fā)和染發(fā)。

          l  擴(kuò)展場(chǎng)景4:理發(fā)店的生意越來(lái)越好,理發(fā)師的數(shù)量和理發(fā)店的門面已經(jīng)無(wú)法滿足顧客的要求,于是理發(fā)店的老板決定在旁邊再開(kāi)一家店,并招聘一些工作能力更強(qiáng)的理發(fā)師。

          l  擴(kuò)展場(chǎng)景5:理發(fā)店的生意變得極為火爆了,兩家店都無(wú)法滿足顧客數(shù)量增長(zhǎng)的需求,并且有些顧客開(kāi)始反映到理發(fā)店的路途太遠(yuǎn),到了以后又因?yàn)闋C發(fā)和染發(fā)的人太多而等太久。可是理發(fā)店的老板也明白燙發(fā)和染發(fā)的收入要遠(yuǎn)遠(yuǎn)高于剪發(fā)阿,于是他腦筋一轉(zhuǎn),決定繼續(xù)改變策略,在附近的幾個(gè)大型小區(qū)租用小的鋪面開(kāi)設(shè)分店,專職剪發(fā)業(yè)務(wù);再在市區(qū)的繁華路段開(kāi)設(shè)旗艦店,專門為燙發(fā)、染發(fā)的顧客,以及VIP顧客服務(wù)。并增設(shè)800電話,當(dāng)顧客想要剪發(fā)時(shí),可以撥打這個(gè)電話,并由服務(wù)人員根據(jù)顧客的居住地點(diǎn),將其指引到距離最近的一家分店去。

          l  這篇文章就先寫(xiě)到這里了,希望大家在看完之后可以繼續(xù)思考一下,也寫(xiě)出自己的心得體會(huì)或者新的想法,記下自己的不解和疑惑,讓我們?cè)诓粩嗟慕涣骱陀懻撝凶叩母h(yuǎn) ^_^

          5.        LoadRunner 沒(méi)有告訴你的》之四——理解性能

          l     如何評(píng)價(jià)性能的優(yōu)劣: 用戶視角 vs. 系統(tǒng)視角

          l  對(duì)于最終用戶(End-User)來(lái)說(shuō),評(píng)價(jià)系統(tǒng)的性能好壞只有一個(gè)字——“快”。最終用戶并不需要關(guān)心系統(tǒng)當(dāng)前的狀態(tài)——即使系統(tǒng)這時(shí)正在處理著成千上萬(wàn)的請(qǐng)求,對(duì)于用戶來(lái)說(shuō),由他所發(fā)出的這個(gè)請(qǐng)求是他唯一需要關(guān)心的,系統(tǒng)對(duì)用戶請(qǐng)求的響應(yīng)速度決定了用戶對(duì)系統(tǒng)性能的評(píng)價(jià)。

          l  而對(duì)于系統(tǒng)的運(yùn)營(yíng)商和開(kāi)發(fā)商來(lái)說(shuō),期望的是能夠讓盡可能多的用戶在任意時(shí)刻都擁有最好的體驗(yàn),這就要確保系統(tǒng)能夠在同一時(shí)間內(nèi)處理更多的用戶請(qǐng)求。正如在《理發(fā)店模型》一文中所描述的:系統(tǒng)的負(fù)載(并發(fā)用戶數(shù))與吞吐量(每秒事務(wù)數(shù))、響應(yīng)時(shí)間以及資源利用率(包括軟硬件資源)之間存在著一個(gè)“此消彼長(zhǎng)”的關(guān)系。因此,從系統(tǒng)的運(yùn)營(yíng)商和開(kāi)發(fā)商的角度來(lái)看,所謂的“性能”是一個(gè)整體的概念,是系統(tǒng)的負(fù)載與吞吐量、可接受的響應(yīng)時(shí)間以及資源利用率之間的平衡。

          l  換句話說(shuō),“好的性能”意味著更大的最佳并發(fā)用戶數(shù)(The Optimum Number of Concurrent Users)和 最大并發(fā)用戶數(shù)(The Maximum Number of Concurrent Users)。有關(guān)“最佳/最大并發(fā)用戶數(shù)”的概念請(qǐng)參見(jiàn)《理發(fā)店模型》一文。

          l  另外,從系統(tǒng)的視角來(lái)看,所需要關(guān)注的還包括三個(gè)與“性能”有關(guān)的屬性:可靠性(Reliability),可伸縮性(Scalability)和 可恢復(fù)性(Recoverability)——我將會(huì)在本系列文章的第五篇“無(wú)處不在的性能測(cè)試”中專門討論這三個(gè)屬性的含義和相關(guān)的實(shí)踐經(jīng)驗(yàn)。

          l  響應(yīng)時(shí)間

          l 

          l  上面這張圖引自段念兄的一份講義,不過(guò)我略作了些修改。從圖中我們可以清楚的看到一個(gè)請(qǐng)求的響應(yīng)時(shí)間是由幾部分時(shí)間組成的,包括

          l  C1:用戶請(qǐng)求發(fā)出前在客戶端需要完成的預(yù)處理所需要的時(shí)間;

          l  C2:客戶端收到服務(wù)器返回的響應(yīng)后,對(duì)數(shù)據(jù)進(jìn)行處理并呈現(xiàn)所需要的時(shí)間;

          l  A1Web/App Server 對(duì)請(qǐng)求進(jìn)行處理所需要的時(shí)間;

          l  A2DB Server 對(duì)請(qǐng)求進(jìn)行處理所需的時(shí)間;

          l  A3Web/App Server 對(duì) DB Server 返回的結(jié)果進(jìn)行處理所需的時(shí)間;

          l  N1:請(qǐng)求由客戶端發(fā)出并達(dá)到Web/App Server 所需要的時(shí)間;

          l  N2:如果需要進(jìn)行數(shù)據(jù)庫(kù)相關(guān)的操作,由Web/App Server 將請(qǐng)求發(fā)送至DB Server 所需要的時(shí)間;

          l  N3DB Server 完成處理并將結(jié)果返回Web/App Server 所需的時(shí)間;

          l  N4Web/App Server 完成處理并將結(jié)果返回給客戶端所需的時(shí)間;

          l  從用戶的角度來(lái)看,響應(yīng)時(shí)間=(C1+C2)+(A1+A2+A3)+(N1+N2+N3+N4);但是從系統(tǒng)的角度來(lái)看,響應(yīng)時(shí)間只包括(A1+A2+A3)+(N1+N2+N3+N4)

          l  在理解了響應(yīng)時(shí)間的組成之后,可以幫助我們通過(guò)對(duì)響應(yīng)時(shí)間的分析來(lái)更好的識(shí)別和定位系統(tǒng)的性能瓶頸。

          l   

          l  吞吐量 vs. 吞吐量

          l  在不同的測(cè)試工具中,對(duì)于吞吐量(Throughput)會(huì)有不同的解釋。例如,在LoadRunner中,這個(gè)指標(biāo)是以字節(jié)數(shù)為單位來(lái)衡量網(wǎng)絡(luò)吞吐量的,而在JMeter中則是以事務(wù)數(shù)/秒為單位來(lái)衡量系統(tǒng)的響應(yīng)能力的。不過(guò)在大多數(shù)英文的性能測(cè)試方面的書(shū)籍或資料中,吞吐量的定義使用的是后者。

          l   

          l  并發(fā)用戶數(shù) 每秒請(qǐng)求數(shù)

          l  這是兩個(gè)容易讓初學(xué)者混淆的概念。

          l  簡(jiǎn)單說(shuō),當(dāng)你在性能測(cè)試工具或者腳本中設(shè)置了100并發(fā)用戶數(shù)后,并不能期望著一定會(huì)有每秒100個(gè)請(qǐng)求發(fā)給服務(wù)器。事實(shí)上,對(duì)于一個(gè)虛擬用戶來(lái)說(shuō),每秒發(fā)出多少請(qǐng)求只跟服務(wù)器返回響應(yīng)的速度有關(guān)。如果虛擬用戶在0.5秒內(nèi)就收到了響應(yīng),那么它會(huì)立即發(fā)出第二個(gè)請(qǐng)求;而如果要一直等待3秒才能得到響應(yīng),它將會(huì)一直等到收到響應(yīng)后才發(fā)出第二個(gè)請(qǐng)求。也就是說(shuō),并發(fā)用戶數(shù)的設(shè)置只是保證服務(wù)器在任一時(shí)刻都有100個(gè)請(qǐng)求需要處理,而并不一定是保證每秒中發(fā)送100個(gè)請(qǐng)求給服務(wù)器。

          l  所以,只有當(dāng)響應(yīng)時(shí)間恰好是1秒時(shí),并發(fā)用戶數(shù)才會(huì)等于每秒請(qǐng)求數(shù);否則,每秒請(qǐng)求數(shù)可能大于并發(fā)用戶數(shù)或小于并發(fā)用戶數(shù)。

          l   

          6.        LoadRunner 沒(méi)有告訴你的》之五——無(wú)所不在的性能測(cè)試

          l  需求階段

          l  我們不可能將一輛設(shè)計(jì)載重為0.75噸的皮卡改裝成載重15噸的大型卡車,如果你面對(duì)的正是這樣的問(wèn)題,那么恐怕你只能重做一輛,而且客戶不會(huì)為你之前那輛付錢。對(duì)于一個(gè)已經(jīng)完成的應(yīng)用系統(tǒng)來(lái)說(shuō)也是如此。

          l  如果我們?cè)谙到y(tǒng)結(jié)構(gòu)確定之前就能夠了解到系統(tǒng)的將要面對(duì)的壓力,用戶的使用習(xí)慣和使用頻度,我們就可以更早也更有效的提前解決或預(yù)防可能發(fā)生的性能缺陷,也將會(huì)極大的減少后期返工和反復(fù)調(diào)優(yōu)所帶來(lái)的工作量。如果我們預(yù)期到系統(tǒng)的容量將會(huì)不斷的增長(zhǎng),我們還可以給出相應(yīng)的解決方案來(lái)低成本的解決這類問(wèn)題,就像上面那輛皮卡,也許你可以有辦法把20輛皮卡捆在一起,或者把15噸的東西分由20輛來(lái)運(yùn)。

          l   

          l  分析設(shè)計(jì)階段

          l  系統(tǒng)性能的優(yōu)化并不是要等待整個(gè)系統(tǒng)全部集成后才能開(kāi)始的,早在分析設(shè)計(jì)階段,我們就可以開(kāi)始考慮系統(tǒng)的技術(shù)架構(gòu)和數(shù)據(jù)庫(kù)部分的優(yōu)化。

          l  數(shù)據(jù)庫(kù)通常位于整個(gè)系統(tǒng)的最底層,如果直到系統(tǒng)上線前才發(fā)現(xiàn)因?yàn)閿?shù)據(jù)庫(kù)設(shè)計(jì)不合理而導(dǎo)致性能極差,通常使用任何一種方法來(lái)優(yōu)化都已經(jīng)于事無(wú)補(bǔ)了。要避免這類問(wèn)題,最常見(jiàn)的做法是在數(shù)據(jù)庫(kù)結(jié)構(gòu)確定后,通過(guò)工具或腳本向數(shù)據(jù)庫(kù)中注入大量的數(shù)據(jù),并模擬各種業(yè)務(wù)的數(shù)據(jù)庫(kù)操作。根據(jù)對(duì)數(shù)據(jù)庫(kù)性能的觀察和分析,對(duì)數(shù)據(jù)庫(kù)表結(jié)構(gòu)和索引進(jìn)行調(diào)整以優(yōu)化數(shù)據(jù)庫(kù)性能。

          l  在系統(tǒng)的技術(shù)架構(gòu)方面,要明白先進(jìn)的技術(shù)并不是解決問(wèn)題的唯一方法,過(guò)于強(qiáng)調(diào)技術(shù)的作用反而會(huì)將你帶入歧途。例如:某些業(yè)務(wù)雖然經(jīng)常面臨著巨大的壓力,并且業(yè)務(wù)本身的復(fù)雜性決定了通過(guò)算法的優(yōu)化來(lái)提高系統(tǒng)的性能收效甚微。但是我們知道用戶對(duì)于該業(yè)務(wù)的實(shí)時(shí)性要求并不高,并且返回結(jié)果對(duì)于不同用戶來(lái)說(shuō)是相同的。那么我們完全可以考慮將每次請(qǐng)求都動(dòng)態(tài)生成返回結(jié)果的方式改為每次用戶請(qǐng)求都返回一個(gè)定期更新的靜態(tài)頁(yè)面。

          l  另外,所謂“先進(jìn)技術(shù)”通常都會(huì)在帶來(lái)某一方面改進(jìn)的同時(shí)帶來(lái)另一方面的問(wèn)題,未經(jīng)試驗(yàn)就盲目的在系統(tǒng)中加入各種流行元素未必是最好的選擇。例如ORM可以提供一些方便,但是它生成的SQL是未經(jīng)優(yōu)化的,有時(shí)甚至比人工編寫(xiě)的SQL效率更低。

          l  最后,要知道不同廠家的設(shè)備性能是不同的,而且不同的硬件設(shè)備搭載不同的操作系統(tǒng)、數(shù)據(jù)庫(kù)、中間件以及應(yīng)用服務(wù)器,表現(xiàn)出來(lái)的性能也是不同的。如果有足夠的資源,應(yīng)當(dāng)考慮提前進(jìn)行軟硬件平臺(tái)的對(duì)比選型;如果沒(méi)有足夠的資源,可以考慮通過(guò)一些專業(yè)的組織或網(wǎng)站來(lái)獲取或購(gòu)買相關(guān)的評(píng)估報(bào)告。

          l   

          l  編碼階段

          l  一片樹(shù)葉在哪里最難被發(fā)現(xiàn)?——當(dāng)這片樹(shù)葉落在一堆樹(shù)葉里面的時(shí)候。

          l  如果你只是在系統(tǒng)測(cè)試完成后才開(kāi)始性能測(cè)試,那么即使發(fā)現(xiàn)系統(tǒng)存在性能缺陷,并且已經(jīng)有了幾個(gè)可供懷疑的對(duì)象,但是當(dāng)一段因?yàn)槭褂昧瞬划?dāng)?shù)乃惴ǘ鴮?dǎo)致執(zhí)行效率很低的代碼藏身于一個(gè)龐大的系統(tǒng)中時(shí),找出它是非常困難的。避免這種情況出現(xiàn)的方法是盡早開(kāi)始核心業(yè)務(wù)代碼的性能測(cè)試,重點(diǎn)集中在對(duì)算法和實(shí)現(xiàn)方法的優(yōu)化上。

          l  另外,及早開(kāi)始的測(cè)試也可以幫你更容易找到內(nèi)存泄漏的問(wèn)題。

          l   

          l  測(cè)試階段

          l  產(chǎn)品終于交到我們手上了,搭建測(cè)試環(huán)境,設(shè)計(jì)測(cè)試場(chǎng)景,執(zhí)行測(cè)試,找到系統(tǒng)的最佳并發(fā)用戶數(shù)和最大并發(fā)用戶數(shù),將系統(tǒng)進(jìn)行分類,評(píng)判系統(tǒng)的性能表現(xiàn)是否滿足需求中定義的目標(biāo)——如果有需求的話 ^_^

          l  如果發(fā)現(xiàn)系統(tǒng)的性能表現(xiàn)與預(yù)期目標(biāo)相去甚遠(yuǎn),則需要根據(jù)執(zhí)行測(cè)試過(guò)程中收集到的數(shù)據(jù)來(lái)分析和識(shí)別性能瓶頸,優(yōu)化系統(tǒng)性能。

          l  在這個(gè)階段還有很多值得我們深入思考和討論的東西,在本系列后續(xù)的文章中,我們將會(huì)更多的關(guān)注這一部分的內(nèi)容。

          l   

          l  維護(hù)階段

          l  維護(hù)階段通常遇到的問(wèn)題是需要在實(shí)驗(yàn)室中模擬客戶環(huán)境,重現(xiàn)在客戶那里發(fā)現(xiàn)的缺陷并修復(fù)缺陷。相比功能缺陷,性能缺陷與某一具體環(huán)境和場(chǎng)景的關(guān)聯(lián)更加密切,所以在測(cè)試前需要檢查生產(chǎn)環(huán)境中各服務(wù)器的資源利用率、系統(tǒng)訪問(wèn)日志、應(yīng)用服務(wù)器的日志、數(shù)據(jù)庫(kù)的日志。如果客戶使用了專門的系統(tǒng)來(lái)監(jiān)測(cè)各個(gè)服務(wù)器的軟硬件資源使用情況的話,檢查該系統(tǒng)是否記錄下了軟硬件資源的異常或者警告。

          l   

          l  與性能測(cè)試相關(guān)的其他測(cè)試

          l  可靠性測(cè)試(Reliability Testing    對(duì)于一個(gè)運(yùn)營(yíng)商級(jí)的系統(tǒng)來(lái)說(shuō),能夠保證提供7×24的連續(xù)穩(wěn)定的服務(wù)是非常重要的。當(dāng)然,你可以通過(guò)一些“高可用性(High Availability)”技術(shù)方案來(lái)增強(qiáng)系統(tǒng)的可靠性,但是對(duì)于系統(tǒng)本身的可靠性測(cè)試是不能被忽略的。

          l  常用的測(cè)試方法是使用一定的負(fù)載長(zhǎng)時(shí)間向服務(wù)器加壓,并觀察隨著加壓時(shí)間的延長(zhǎng),響應(yīng)時(shí)間、吞吐量以及資源利用率的變化。要注意的是,所使用的負(fù)載應(yīng)當(dāng)是系統(tǒng)的最佳并并發(fā)用戶數(shù),而不是最大并發(fā)用戶數(shù)。

          l  可伸縮性測(cè)試(Scalability Testing 對(duì)于一個(gè)系統(tǒng)來(lái)說(shuō),在一個(gè)給定的環(huán)境下,它的最佳并發(fā)用戶數(shù)和最大并發(fā)用戶數(shù)是客觀存在的,但是系統(tǒng)所面臨的壓力卻有可能隨上線時(shí)間的延長(zhǎng)而增大。例如,一個(gè)在線購(gòu)物站點(diǎn),注冊(cè)用戶數(shù)量不斷增多,訪問(wèn)站點(diǎn)查詢商品信息和購(gòu)買商品的人也不斷的增多,我們應(yīng)該用一種什么樣的方案,在不影響系統(tǒng)繼續(xù)為用戶提供服務(wù)的前提下來(lái)實(shí)現(xiàn)系統(tǒng)的擴(kuò)容?

          l  一種常用的方案是使用負(fù)載均衡(Load Balance)和集群(Cluster)技術(shù)。但是在我們?yōu)榭蛻籼峁┻@種方案之前,需要先自己進(jìn)行測(cè)試,保證該技術(shù)的有效性——我們是否真的可以通過(guò)簡(jiǎn)單的增加服務(wù)器數(shù)據(jù)和修改某些參數(shù)配置,就能夠使得系統(tǒng)的容量得到線性的增長(zhǎng)?

          l  可恢復(fù)性測(cè)試(Recoverability Testing      雖然我們已經(jīng)可以準(zhǔn)確的估算出系統(tǒng)上線后將要面對(duì)的壓力,并且可以保證系統(tǒng)的最佳并發(fā)用戶數(shù)和最大并發(fā)用戶數(shù)是足以應(yīng)對(duì)這些壓力的,但是這個(gè)世界上總是有些事情上我們所無(wú)法預(yù)料到的——例如9.11事件發(fā)生后,AOL的網(wǎng)站訪問(wèn)量在短時(shí)間內(nèi)增長(zhǎng)到了平時(shí)的數(shù)十倍。

          l  我們無(wú)法保證系統(tǒng)可以在任何情況下都能為用戶正確無(wú)誤的提供服務(wù),但是我們需要確保當(dāng)意外過(guò)去后,系統(tǒng)可以恢復(fù)到正常的狀態(tài),并繼續(xù)后來(lái)的用戶提供服務(wù)——就像從未發(fā)生過(guò)任何事情一樣。

          l  如果要實(shí)現(xiàn)“可恢復(fù)性測(cè)試”,我們可以借助于測(cè)試工具或腳本來(lái)逐漸的增大并發(fā)用戶數(shù),直至并發(fā)用戶數(shù)已經(jīng)超過(guò)了系統(tǒng)所能承受的最大并發(fā)用戶數(shù),并導(dǎo)致軟硬件資源利用率飽和,響應(yīng)時(shí)間無(wú)限延長(zhǎng),大量的請(qǐng)求因?yàn)槌^(guò)響應(yīng)時(shí)間要求或無(wú)法獲得響應(yīng)而失敗;之后,我們逐漸的減少并發(fā)用戶數(shù),并觀察資源利用率、響應(yīng)時(shí)間、吞吐量以及交易成功率的變化是否與預(yù)期目標(biāo)一致。

          l   

          l  當(dāng)然,這一切的前提是在系統(tǒng)負(fù)載達(dá)到峰值前,Server一直在頑強(qiáng)的掙扎著而沒(méi)有down ^_^

          l 

          l  性能測(cè)試,并非網(wǎng)絡(luò)應(yīng)用專屬

          l  軟件的性能和性能測(cè)試都是伴隨著網(wǎng)絡(luò)應(yīng)用的興起而逐漸被重視起來(lái)的,但是軟件性能和性能測(cè)試卻并非網(wǎng)絡(luò)應(yīng)用的專屬名詞,因?yàn)閱螜C(jī)版的應(yīng)用同樣需要考慮性能問(wèn)題。下面舉幾個(gè)簡(jiǎn)單的例子來(lái)方便大家的理解:

          l  1.               當(dāng)使用Word來(lái)編輯一個(gè)500多頁(yè),并包含了豐富圖表、圖片和各種格式、樣式信息的文檔時(shí),是否每次對(duì)大段的文字或表格的修改、刪除或重新排版,都要等待系統(tǒng)花幾秒鐘的時(shí)間進(jìn)行處理?

          l  2.              當(dāng)在Excel中使用嵌套的統(tǒng)計(jì)和數(shù)學(xué)函數(shù)對(duì)幾萬(wàn)行記錄進(jìn)行統(tǒng)計(jì)分析時(shí),是否每次都要兩三分鐘才能看到結(jié)果?

          l  3.              殺毒軟件是否每次都要花費(fèi)兩個(gè)小時(shí)才能完成一次對(duì)所有的分區(qū)的掃描?

          l  4.              是否每次在手機(jī)的通訊簿中根據(jù)姓名搜索某個(gè)人的聯(lián)系方式都要三四秒鐘才有響應(yīng)?

          l  如果大家有興趣,也可以通過(guò)Google搜索到更多的有關(guān)單機(jī)應(yīng)用性能測(cè)試的資料。

          7.        LoadRunner沒(méi)有告訴你的》之六——獲取有效的性能需求

          l         一個(gè)實(shí)際的例子

          l  為了便于大家的理解,我們先來(lái)看一個(gè)性能需求的例子,讓大家有一個(gè)感性的認(rèn)識(shí),本文后面的討論也會(huì)再次提到這個(gè)例子。

          l  這是一個(gè)證券行業(yè)系統(tǒng)中某個(gè)業(yè)務(wù)的“實(shí)際需求”——實(shí)際上是我根據(jù)通過(guò)網(wǎng)絡(luò)搜集到的數(shù)據(jù)杜撰出來(lái)的,不過(guò)看起來(lái)像是真實(shí)的 ^_^

          l  l         系統(tǒng)總?cè)萘窟_(dá)到日委托6000萬(wàn)筆,成交9000萬(wàn)筆

          l  l         系統(tǒng)處理速度每秒7300筆,峰值處理能力達(dá)到每秒10000

          l  l         實(shí)際股東帳號(hào)數(shù)3000萬(wàn)

          l  這個(gè)例子中已經(jīng)包括幾個(gè)明確的需求:

          l  l         最佳并發(fā)用戶數(shù)需求:每秒7300

          l  l         最大并發(fā)用戶數(shù)需求:峰值處理能力達(dá)到每秒10000

          l  l         基礎(chǔ)數(shù)據(jù)容量:實(shí)際股東帳號(hào)數(shù)3000萬(wàn)

          l  l         業(yè)務(wù)數(shù)據(jù)容量:日委托6000萬(wàn)筆,成交9000萬(wàn)筆——可以根據(jù)這個(gè)推算出每周、每月、每年系統(tǒng)容量的增長(zhǎng)模型

          l  什么是“有效的”性能需求?

          l  要想獲得有效的性能需求,就要先了解什么樣的需求是“有效的”。有效的性能需求應(yīng)該符合以下三個(gè)條件。

          l  1.     明確的數(shù)字,而不是模糊的語(yǔ)句。

          l  結(jié)合上面的例子來(lái)看,相信這個(gè)應(yīng)該不難理解。但是有的時(shí)候有了數(shù)字未必就不模糊。例如常見(jiàn)的一種需求是“系統(tǒng)需要支持5000用戶”,或者“最大在線用戶數(shù)為8000。這些有數(shù)字的需求仍然不夠明確,因?yàn)檫€需要考慮區(qū)分系統(tǒng)中不同業(yè)務(wù)模塊的負(fù)載,以及區(qū)分在線用戶和并發(fā)用戶的區(qū)別。關(guān)于這方面的內(nèi)容,在下面兩篇文章中的留言內(nèi)容中有精彩的討論:

          l  http://www.cnblogs.com/jackei/archive/2006/11/15/560578.html

          l  http://www.cnblogs.com/jackei/archive/2006/11/16/561846.html

          l  2.     有憑有據(jù),合理,有實(shí)際意義。

          l  通常來(lái)說(shuō),性能需求要么由客戶提出,要么由開(kāi)發(fā)方提出。對(duì)于第一種情況,要保證需求是合理的,有現(xiàn)實(shí)意義的,不能由著客戶使勁往高處說(shuō),要讓客戶明白性能是有成本的。對(duì)于第二種情況,性能需求不能簡(jiǎn)單的來(lái)源于項(xiàng)目組成員、PM或者測(cè)試工程師的估計(jì)或者猜測(cè),要保證性能需求的提出是有根據(jù)的,所使用的數(shù)據(jù)和計(jì)算公式是有出處的——本文后面的部分會(huì)介紹獲得可用的數(shù)據(jù)和計(jì)算公式的方法。

          l  3.     相關(guān)人員達(dá)成一致。

          l  這一點(diǎn)非常關(guān)鍵。如果相關(guān)人不能對(duì)性能需求達(dá)成一致,可能測(cè)了也白測(cè)——特別是在客戶沒(méi)有提出明確的性能需求而由開(kāi)發(fā)方提出時(shí)。這里要注意“相關(guān)人員”的識(shí)別,通常項(xiàng)目型的項(xiàng)目的需要與客戶方的項(xiàng)目經(jīng)理或負(fù)責(zé)人進(jìn)行確認(rèn),產(chǎn)品型的項(xiàng)目需要與直屬領(lǐng)導(dǎo)或者市場(chǎng)部進(jìn)行確認(rèn)。如果實(shí)在不知道該找誰(shuí)確認(rèn),那就把這個(gè)責(zé)任交給你的直屬領(lǐng)導(dǎo);如果你就是領(lǐng)導(dǎo)了,那這領(lǐng)導(dǎo)也白當(dāng)了 ^_^

          l   

          l  如何獲得有效的性能需求

          l  上面提到了“有效的”性能需求的一個(gè)例子和三個(gè)條件,下面來(lái)我們將看到有哪些途徑可以幫助我們獲得相關(guān)的數(shù)據(jù)——這些方法我在實(shí)際的工作中都用過(guò),并且已經(jīng)被證實(shí)是可行的。這幾種方法由易到難排列如下:

          l  1.       客戶方提出

          l  這是最理想的一種方式,通常電信、金融、保險(xiǎn)、證券以及一些其他運(yùn)營(yíng)商級(jí)系統(tǒng)的客戶——特別是國(guó)外的客戶都會(huì)提出比較明確的性能需求。

          l  2.       根據(jù)歷史數(shù)據(jù)來(lái)分析

          l  根據(jù)客戶以往的業(yè)務(wù)情況來(lái)分析客戶的業(yè)務(wù)量以及每年、每月、每周、每天的峰值業(yè)務(wù)量。如果客戶有舊的系統(tǒng),可以根據(jù)已有系統(tǒng)的訪問(wèn)日志,數(shù)據(jù)庫(kù)記錄,業(yè)務(wù)報(bào)表來(lái)分析。要特別注意的是,不同行業(yè)、不同應(yīng)用、不同的業(yè)務(wù)是有各自的特點(diǎn)的。例如,購(gòu)物網(wǎng)站在平時(shí)的負(fù)載主要集中在晚上,但是節(jié)假日時(shí)訪問(wèn)量和交易量會(huì)是平時(shí)的數(shù)倍;而地鐵的售票系統(tǒng)面臨的高峰除了周末,還有周一到周五的一早一晚上下班時(shí)間。

          l  3.       參考?xì)v史項(xiàng)目的數(shù)據(jù)

          l  如果該產(chǎn)品已有其他客戶使用,并且規(guī)模類似的,可以參考其他客戶的需求。例如在線購(gòu)物網(wǎng)站,或者超市管理系統(tǒng),各行業(yè)的進(jìn)銷存系統(tǒng)。

          l  4.       參考其他同行類似項(xiàng)目的數(shù)據(jù)

          l  如果本企業(yè)沒(méi)有做過(guò)類似的項(xiàng)目,那么可以參考其他同行企業(yè)的公布出來(lái)的數(shù)據(jù)——通常在企業(yè)公布的新聞或者成功解決方案中會(huì)提到,包括系統(tǒng)容量,系統(tǒng)所能承受的負(fù)載以及系統(tǒng)響應(yīng)能力等。

          l  5.       參考其他類似行業(yè)應(yīng)用的數(shù)據(jù)

          l  如果無(wú)法找打其他同行的數(shù)據(jù),也可以參考類似的應(yīng)用的需求。例如做IPTV或者DVB計(jì)費(fèi)系統(tǒng)的測(cè)試,可以參考電信計(jì)費(fèi)系統(tǒng)的需求——雖然不能完全照搬數(shù)據(jù),但是可以通過(guò)其他行業(yè)成熟的需求來(lái)了解需要測(cè)試的項(xiàng)目有哪些,應(yīng)該考慮到的情況有哪些種。

          l  6.       參考新聞或其他資料中的數(shù)據(jù)

          l  最后的一招,特別是對(duì)于一些當(dāng)前比較引人關(guān)注的行業(yè),涉及到所謂的“政績(jī)”的行業(yè),通常可以通過(guò)各種新聞媒體找到一些可供參考的數(shù)據(jù),但是需要耐心的尋找。例如我們?cè)?/span>IPTVDVB系統(tǒng)的測(cè)試中,可以根據(jù)新聞中公布的各省、各市,以及國(guó)外各大運(yùn)營(yíng)商的用戶發(fā)展情況和用戶使用習(xí)慣來(lái)估算系統(tǒng)容量和系統(tǒng)各個(gè)模塊的并發(fā)量。

          l  又一塊磚拋出來(lái)了,希望大家在看完之后也有更多的玉丟過(guò)來(lái) ^_^

          8.        LoadRunner沒(méi)有告訴你的》之七——使用 LoadRunner 連續(xù)長(zhǎng)時(shí)間執(zhí)行測(cè)試,如何保證參數(shù)化的數(shù)據(jù)足夠又不會(huì)重復(fù)?

          l  有朋友開(kāi)始投訴了,說(shuō)我已經(jīng)好長(zhǎng)一段時(shí)間沒(méi)有寫(xiě)技術(shù)類文章了。汗顏,積極改進(jìn)。剛好今天在群里有同行遇到一個(gè)關(guān)于 LR 參數(shù)化的問(wèn)題,其實(shí)這個(gè)問(wèn)題以前也遇到過(guò),所以就順便把我的想法整理一下發(fā)上來(lái)。

          l  當(dāng)時(shí)我們要做的是使用性能測(cè)試工具模擬大量用戶在線點(diǎn)播 Movie 的業(yè)務(wù),這個(gè)點(diǎn)播 Movie 的業(yè)務(wù)在第一次點(diǎn)播成功后,如果同一用戶再次點(diǎn)播同一 Movie,系統(tǒng)的處理流程與第一次點(diǎn)播是不同的。另外,我們?cè)趫?zhí)行測(cè)試時(shí),通常都會(huì)連續(xù)執(zhí)行幾個(gè)小時(shí)以獲得盡可能多的樣本數(shù)據(jù)。

          l  那么問(wèn)題就在于,一方面我們不能在一次測(cè)試中重復(fù)的讀取同樣的數(shù)據(jù),另一方面準(zhǔn)備幾十萬(wàn)甚至上百萬(wàn)的數(shù)據(jù)工作量也太大,而且還涉及到相關(guān)的基礎(chǔ)數(shù)據(jù)的準(zhǔn)備。那么,我們?cè)撊绾卧谑褂?/span> LoadRunner 連續(xù)長(zhǎng)時(shí)間執(zhí)行測(cè)試,保證參數(shù)化的數(shù)據(jù)充足而又不會(huì)重復(fù)呢?

          l  其實(shí)方法很簡(jiǎn)單。無(wú)論上 LR 還是 JMeter,都提供了將多個(gè)參數(shù)的取值存放在同一個(gè)文件中,或者每個(gè)參數(shù)單獨(dú)指定一個(gè)文件的功能,針對(duì)上面這個(gè)例子,我們只是簡(jiǎn)單的創(chuàng)建了兩個(gè)文件和三個(gè)參數(shù),第一個(gè)參數(shù)和第二個(gè)參數(shù)(用戶賬號(hào)和密碼)存放在第一個(gè)文件中,有1000條記錄;第三個(gè)參數(shù)(Movie ID)存放在第二個(gè)文件中,有999條記錄。然后在測(cè)試工具中設(shè)置參數(shù)取值的讀取為順序讀取并且循環(huán)讀取。通過(guò)這種簡(jiǎn)單的方法組合出了大量的數(shù)據(jù)。

          l  問(wèn)題被解決了。

          9.        LoadRunner--Think Time

          l  Think Time”顧名思義-思考時(shí)間。它效仿真實(shí)用戶在實(shí)際操作過(guò)程中的等待時(shí)間。也就是說(shuō),實(shí)際用戶在瀏覽網(wǎng)頁(yè),操作B/S系統(tǒng)的時(shí)候,不可能像機(jī)器一樣不停的點(diǎn)啊點(diǎn),在操作和操作之間會(huì)有一定的間隔。如:你瀏覽網(wǎng)頁(yè),打開(kāi)一個(gè)或幾個(gè)網(wǎng)頁(yè)后,你會(huì)閱讀,讀過(guò)之后才會(huì)繼續(xù)打開(kāi)新網(wǎng)頁(yè)。你閱讀時(shí)所消耗的時(shí)間就是Think Time。對(duì)于服務(wù)器來(lái)說(shuō),這段時(shí)間是沒(méi)有壓力的。

          l  我們做性能測(cè)試,很多時(shí)候就要模擬這種狀態(tài)。例如:某系統(tǒng),要求滿足100用戶同時(shí)在線操作,響應(yīng)時(shí)間在5秒。如果不設(shè)置Think Time,我覺(jué)得,你的測(cè)試是失敗的。大家想想為什么?答案將在文章的結(jié)尾揭曉。

          l  下面我來(lái)講解一下LRThink Time的設(shè)置。

          l  設(shè)置Think Time有兩種方式,一種是使用Record think time在錄制過(guò)程中根據(jù)實(shí)際等待時(shí)間自動(dòng)的寫(xiě)入腳本。另一種是在腳本錄制結(jié)束后手動(dòng)加入到腳本中。接下來(lái)我們?cè)敿?xì)介紹。

          l  自動(dòng):

          l  位置及操作:Recording OptionAdvanced:勾上Record think time,這樣在你錄制的時(shí)候,Think Time就會(huì)自動(dòng)添加入你的腳本。需要注意的是,后面還有一項(xiàng)Think time threshold,它的作用是定義你所要錄制的Think Time的最小時(shí)間。舉個(gè)例子,如果你把這個(gè)值設(shè)置為5秒,那么如果錄制過(guò)程中等待的時(shí)間小于5秒,那么就不會(huì)在腳本中記錄這個(gè)Think Time

          l  手動(dòng):

          l  位置及操作:腳本中任何你想要插入的地方。注意,不要將Think Time插入到你定義的事務(wù)當(dāng)中,否則,測(cè)出的事務(wù)時(shí)間需要減去Think Time的時(shí)間呦。操作:在你想要插入Think Time的地方,右鍵,InsertNew StepTime To Think () second在空中填寫(xiě)你為想要設(shè)置的時(shí)間。也可以在腳本中直接寫(xiě)函數(shù)lr_think_time();

          l  添加好后,我們?cè)?/span>Run-time Settings中設(shè)置執(zhí)行的策略。

          l  位置:Run-time SettingsThink Time。進(jìn)入后,我們會(huì)看到兩個(gè)選項(xiàng)。Ignore think time:忽略think time,也就是即使你添加了think time,腳本執(zhí)行的時(shí)候也不會(huì)理睬,忽略不執(zhí)行。Replay the think time:下面還有3個(gè)子項(xiàng)。As recorded:按照錄制的執(zhí)行。不用多說(shuō)。Multiply recorded think time by:這就是我錄制的think time乘一個(gè)系數(shù)。如,你錄制的think time4秒,在這里設(shè)置2,最后執(zhí)行時(shí)就會(huì)按4秒×2=8秒來(lái)執(zhí)行。如果你想要執(zhí)行2秒,就在這里填0.5Use random percentage of the recorded think time:這里隨機(jī)設(shè)置一個(gè)百分比,并規(guī)定上下限。如,錄制的think time4秒。Min50%,Max200%。那么執(zhí)行的時(shí)候它就會(huì)從2秒到8秒內(nèi)隨機(jī)取一個(gè)數(shù)來(lái)執(zhí)行。Limit think time to:為think time設(shè)置一個(gè)上限,不管上面的如何設(shè)置,執(zhí)行的時(shí)候,取值都不會(huì)操過(guò)這個(gè)上限。

          l  講到這里,think time的設(shè)置大家應(yīng)該很明白了。不知道讓大家思考的問(wèn)題是否想通了。需求說(shuō)的是100用戶同時(shí)在線操作,注意,是在線!大家想想,100人在線肯定有人在操作,也有人只是在線,沒(méi)有對(duì)服務(wù)器發(fā)出任何請(qǐng)求。如果不設(shè)置think time,相當(dāng)于100人并發(fā)操作,每個(gè)人都不停的向服務(wù)器發(fā)送請(qǐng)求,這比需求的壓力可是大很多的呦~

          10.    LoadRunner--關(guān)聯(lián)(correlation

          l  所謂的關(guān)聯(lián)(correlation)就是把腳本中某些寫(xiě)死的(hard-coded)資料,轉(zhuǎn)變成是摘取自服務(wù)器所送的、動(dòng)態(tài)的、每次都不一樣的資料。舉一個(gè)常見(jiàn)的例子,剛剛提到有些比較聰明的服務(wù)器,這些服務(wù)器在每個(gè)瀏覽器第一次跟它要資料時(shí),都會(huì)在資料中夾帶一個(gè)唯一的辨識(shí)碼,接下來(lái)就會(huì)利用這個(gè)辨識(shí)碼來(lái)辨識(shí)跟它要資料的是不是同一個(gè)瀏覽器。一般稱這個(gè)辨識(shí)碼為Session ID。對(duì)于每個(gè)新的交易,服務(wù)器都會(huì)產(chǎn)生新的Session ID給瀏覽器。這也就是為什么執(zhí)行腳本會(huì)失敗的原因,因?yàn)?/span>VuGen還是用舊的Session ID向服務(wù)器要資料,服務(wù)器會(huì)發(fā)現(xiàn)這個(gè)Session ID是失效的或是它根本不認(rèn)識(shí)這個(gè)Session ID,當(dāng)然就不會(huì)傳送正確的網(wǎng)頁(yè)資料給VuGen了。

          l  當(dāng)錄制腳本時(shí),瀏覽器送出網(wǎng)頁(yè)A的請(qǐng)求,服務(wù)器將網(wǎng)頁(yè)A的內(nèi)容傳送給瀏覽器,并且?jiàn)A帶了一個(gè)ID=123的資料,當(dāng)瀏覽器再送出網(wǎng)頁(yè)B的情求時(shí),這時(shí)就要用到ID=123的資料,服務(wù)器才會(huì)認(rèn)為這是合法的請(qǐng)求,并且把網(wǎng)頁(yè)B的內(nèi)容送回給瀏覽器。

          l  在執(zhí)行腳本時(shí)會(huì)發(fā)生什么狀況?瀏覽器再送出網(wǎng)頁(yè)B的請(qǐng)求時(shí),用的還是當(dāng)初錄制的ID=123的資料,而不是用服務(wù)器新給的ID=456,整個(gè)腳本的執(zhí)行就會(huì)失敗。要對(duì)付這種服務(wù)器,我們必須想辦法找出這個(gè)Session ID到底是什么、位于何處,然后把它摘取下來(lái),放到某個(gè)參數(shù)中,并且取代掉腳本中有用到Session ID的部份,這樣就可以成功騙過(guò)服務(wù)器,正確地完成整個(gè)交易了。



          天貓 軟件自動(dòng)化測(cè)試開(kāi)發(fā)

          posted on 2014-03-08 17:40 zouhui 閱讀(1917) 評(píng)論(0)  編輯  收藏 所屬分類: 2.軟件測(cè)試 性能自動(dòng)化
          <2014年3月>
          2324252627281
          2345678
          9101112131415
          16171819202122
          23242526272829
          303112345

          常用鏈接

          留言簿(2)

          隨筆分類(94)

          隨筆檔案(94)

          搜索

          •  

          最新評(píng)論

          閱讀排行榜

          評(píng)論排行榜

          主站蜘蛛池模板: 建平县| 正宁县| 永新县| 库伦旗| 双鸭山市| 遂昌县| 沙雅县| 茌平县| 岗巴县| 绥中县| 夏邑县| 山丹县| 汪清县| 济宁市| 德州市| 汉寿县| 烟台市| 方山县| 淳安县| 孝义市| 于田县| 潜江市| 上杭县| 沧源| 惠州市| 苍梧县| 新昌县| 石柱| 重庆市| 建宁县| 塔城市| 潮州市| 科技| 高安市| 昭平县| 盐津县| 康平县| 南陵县| 雷山县| 错那县| 运城市|