LoadRunner壓力測(cè)試結(jié)果分析探討

1、LoadRunner壓力測(cè)試結(jié)果分析探討分析原則：1. 具體問題具體分析（這是由于不同的應(yīng)用系統(tǒng)，不同的測(cè)試目的，不同的性能關(guān)注點(diǎn)）2. 查找瓶頸時(shí)按以下順序，由易到難。服務(wù)器硬件瓶頸 網(wǎng)絡(luò)瓶頸（對(duì)局域網(wǎng)，可以不考慮） 服務(wù)器操作系統(tǒng)瓶頸（參數(shù)配置） 中間件瓶頸（參數(shù)配置，數(shù)據(jù)庫，web服務(wù)器等） 應(yīng)用瓶頸（SQL語句、數(shù)據(jù)庫設(shè)計(jì)、業(yè)務(wù)邏輯、算法等）分析的信息來源：1. 根據(jù)場景運(yùn)行過程中的錯(cuò)誤提示信息2. 根據(jù)測(cè)試結(jié)果收集到的監(jiān)控指標(biāo)數(shù)據(jù)一錯(cuò)誤提示分析分析實(shí)例：1Error: Failed to connect to server “30: 10060 Connectio

2、nError: timed out Error: Server “30 has shut down the connection prematurely分析：A、應(yīng)用服務(wù)死掉。（小用戶時(shí)：程序上的問題。程序上處理數(shù)據(jù)庫的問題，實(shí)際測(cè)試中多半是服務(wù)器鏈接的配置問題）B、應(yīng)用服務(wù)沒有死（應(yīng)用服務(wù)參數(shù)設(shè)置問題）對(duì)應(yīng)的Apache和tomcat的最大鏈接數(shù)需要修改，如果連接時(shí)收到connection refused消息，說明應(yīng)提高相應(yīng)的服務(wù)器最大連接的設(shè)置，增加幅度要根據(jù)實(shí)際情況和服務(wù)器硬件的情況來定，建議每次增加25%！C、數(shù)據(jù)庫的連接(數(shù)據(jù)庫啟動(dòng)的最大連接數(shù)（跟硬件的內(nèi)存有關(guān)）

3、)D、我們的應(yīng)用程序spring控制的最大鏈接數(shù)太低2. Error: Page download timeout (120 seconds) has expired分析：A、應(yīng)用服務(wù)參數(shù)設(shè)置太大導(dǎo)致服務(wù)器的瓶頸B、頁面中圖片太多C、在程序處理表的時(shí)候檢查字段太大多D、實(shí)際測(cè)試時(shí)有些資源需要請(qǐng)求外網(wǎng)，而我們的測(cè)試環(huán)境是局域網(wǎng)環(huán)境3. Error “30/Home.do.”分析：A、腳本設(shè)計(jì)錯(cuò)誤，造成頁面異常。服務(wù)器有響應(yīng)！B、并發(fā)數(shù)過大，造成服務(wù)器響應(yīng)延遲。4. Error page “text=xxxxx”分析：A、腳本設(shè)計(jì)問題，例如，前一腳本修改了某些內(nèi)容，

4、造成后面的腳本訪問異常。B、不確定因素，有時(shí)候回放正常的腳本，一放到場景中就出現(xiàn)這樣的錯(cuò)誤。只能反復(fù)修改腳本！二監(jiān)控指標(biāo)數(shù)據(jù)分析1Vusers數(shù)Loadrunner 系統(tǒng)設(shè)置的虛擬用戶數(shù)目。Vuser去實(shí)際調(diào)用事先制作的腳本文件中的應(yīng)用。每個(gè)Vuser產(chǎn)生響應(yīng)的操作，所有的操作對(duì)服務(wù)器形成并發(fā)。顏色 比例 度量 圖最小值 圖平均值 圖最大值 圖中間值 圖SD1 Run 0.0 21.25 44 41 21.276在實(shí)際測(cè)試中，Vusers可以根據(jù)實(shí)際情況的需要，在測(cè)試過程中增加或者減少。2最大并發(fā)用戶數(shù)：顏色 比例 度量 最小值 平均值 最大值 SD100 Apache CPU 使用情況(Ap

5、ache):10 0.777 0.852 0.93 0.0430.01 已發(fā)送 KB/秒(Apache):10 6 1430.371 2689.333 327.9240.1 點(diǎn)擊次數(shù)/秒(Apache):10 0.333 114.352 533.667 40.201應(yīng)用系統(tǒng)在當(dāng)前環(huán)境下能承受的最大并發(fā)用戶數(shù)。在方案運(yùn)行中，如果出現(xiàn)了大批用戶的業(yè)務(wù)操作失敗，或出現(xiàn)了服務(wù)器shutdown的情況，則說明在當(dāng)前環(huán)境下，系統(tǒng)承受不了當(dāng)前并發(fā)用戶的負(fù)載壓力，那么最大并發(fā)用戶數(shù)就是前一個(gè)沒有出現(xiàn)這種現(xiàn)象的并發(fā)用戶數(shù)。從上圖可以看出：在測(cè)試運(yùn)行到4

6、個(gè)小時(shí)左右的時(shí)候，apache的點(diǎn)擊數(shù)/秒開始迅速增加！3業(yè)務(wù)操作響應(yīng)時(shí)間：使用“事務(wù)性能摘要”圖，可以確定在方案執(zhí)行期間響應(yīng)時(shí)間過長的事務(wù)。顏色 比例 度量1 最小值1 平均值1 最大值分析事務(wù)的響應(yīng)情況，要每次詳細(xì)分析，目前還只能觀察到響應(yīng)時(shí)間過長的事務(wù)！4每秒點(diǎn)擊數(shù)負(fù)載測(cè)試期間每秒內(nèi) Vuser 在 Web 服務(wù)器上點(diǎn)擊的次數(shù)?？筛鶕?jù)點(diǎn)擊次數(shù)來估算 Vuser 生成的負(fù)載數(shù)。顏色 比例 度量 圖最小值 平均值 圖最大值 圖中間值 圖SD1 點(diǎn)擊次數(shù) 69.908 105.736 130.244 103.666 12.186從圖中不難看出，在4小時(shí)的時(shí)候，點(diǎn)技數(shù)明顯增高。和apache的每

7、秒點(diǎn)擊數(shù)增大的時(shí)間相吻合！5吞吐量負(fù)載測(cè)試期間 Web 服務(wù)器上的吞吐量(字節(jié))。吞吐量表示在任何指定秒內(nèi) Vuser 從服務(wù)器接收到的數(shù)據(jù)量。此圖可估計(jì) Vuser 生成的負(fù)載量(服務(wù)器吞吐量)。顏色 比例 度量 圖最小值 平均值 圖最大值 圖中間值 圖SD1 Throughput .795 .372 .047 .691 49130.473同樣，從圖中可以看出，在4個(gè)小時(shí)的時(shí)候，web服務(wù)器的吞吐量開始增高。在圖中還可以看到吞吐量的走勢(shì)圖，從開始到進(jìn)行到4個(gè)小時(shí)反彈之前呈降低的趨勢(shì)，這是因?yàn)橄到y(tǒng)在初期調(diào)用的資源都是直接來之服務(wù)器，運(yùn)行一段時(shí)間后系統(tǒng)的部分資源來自緩存。6下載組件大小每個(gè)頁面的

8、組件大小，且包括組件的標(biāo)頭的大??！頁面組件大小的分析表格比較復(fù)雜，實(shí)際分析中可以通過loadrunner的報(bào)告分析工具來分析。頁面組件大小分析主要是找到頁面中比較龐大的組件，如果其影響到了頁面的下載速度，則要想辦法將其改??！7Apache資源顯示APACHE web服務(wù)器上的資源摘要。前面已經(jīng)提到過以并發(fā)點(diǎn)擊數(shù)為主。顏色 比例 度量 最小值 平均值 最大值 SD100 Apache CPU 使用情況(Apache):10 0.777 0.852 0.93 0.0430.01 已發(fā)送 KB/秒(Apache):10 6 1430.371 2689.333

9、327.9240.1 點(diǎn)擊次數(shù)/秒(Apache):10 0.333 114.352 533.667 40.201三服務(wù)器資源監(jiān)控指標(biāo)：（目前通過top監(jiān)察）內(nèi)存：Linux資源監(jiān)控中指標(biāo)內(nèi)存頁交換速率（Paging rate），如果該值偶爾走高，表明當(dāng)時(shí)有線程競爭內(nèi)存。如果持續(xù)很高，則內(nèi)存可能是瓶頸。也可能是內(nèi)存訪問命中率低。實(shí)際測(cè)試中，當(dāng)并發(fā)點(diǎn)擊數(shù)出現(xiàn)突然劇增前后，內(nèi)存的PR 值則居高25不下。說明目前測(cè)試的系統(tǒng)中內(nèi)存存在瓶頸！內(nèi)存資源成為系統(tǒng)性能的瓶頸的征兆:很高的換頁率(high pageout rate);進(jìn)程進(jìn)入不活動(dòng)狀態(tài);交換區(qū)所有磁盤的活動(dòng)次數(shù)可高;可高的全

10、局系統(tǒng)CPU利用率;內(nèi)存不夠出錯(cuò)(out of memory errors)處理器：Linux資源監(jiān)控中指標(biāo)CPU占用率持續(xù)超過80%（對(duì)該值的要求，根據(jù)具體應(yīng)用和機(jī)器配置而要求不同，有資料表明95），表明瓶頸是CPU。實(shí)際測(cè)試中，當(dāng)并發(fā)點(diǎn)技數(shù)出現(xiàn)突然增加前后，cpu的占用率持續(xù)保持在86以上！說明，目前系統(tǒng)用應(yīng)用的cpu也是測(cè)試的瓶頸！CPU資源成為系統(tǒng)性能的瓶頸的征兆:很慢的響應(yīng)時(shí)間(slow response time)CPU空閑時(shí)間為零(zero percent idle CPU)過高的用戶占用CPU時(shí)間(high percent user CPU)過高的系統(tǒng)占用CPU時(shí)間(high

11、percent system CPU)長時(shí)間的有很長的運(yùn)行進(jìn)程隊(duì)列(large run queue size sustained over time)四數(shù)據(jù)庫服務(wù)器：數(shù)據(jù)庫服務(wù)器目前測(cè)試觀察，當(dāng)web服務(wù)器點(diǎn)擊率增大時(shí)，觀察mysql數(shù)據(jù)庫的最大連接數(shù)，仍未超過系統(tǒng)設(shè)置的最大連接數(shù)。所以，暫時(shí)未發(fā)現(xiàn)數(shù)據(jù)庫的瓶頸！五結(jié)論以上報(bào)告分析中的數(shù)據(jù)、圖標(biāo)均來自同一次測(cè)試。是在平時(shí)測(cè)試中挑出的一次現(xiàn)象比較明顯，比較利于觀察的作為分析案例。根據(jù)以上綜合分析，當(dāng)前測(cè)試環(huán)境下，當(dāng)應(yīng)用系統(tǒng)產(chǎn)生最大533.667的并發(fā)壓力。平均負(fù)載壓力114.352。根據(jù)分析，用戶在4個(gè)小時(shí)的時(shí)候，并發(fā)數(shù)迅速增加前后的值在400左

12、右！分析結(jié)果跟實(shí)際測(cè)試的硬件環(huán)境以及測(cè)試腳本有一定關(guān)系。同時(shí)，測(cè)試服務(wù)器的硬件配置和實(shí)際服務(wù)器的配置還有一定的差距！轉(zhuǎn)一份在 51testing 上的討論如何測(cè)試一個(gè)門戶網(wǎng)站是否可以支持10萬用戶同時(shí)在線？ Posted on 2006-11-16 01:21 Jackei 閱讀(6074) 評(píng)論(5) 編輯 收藏 網(wǎng)摘 所屬分類: 04.軟件性能測(cè)試 這個(gè)帖子的內(nèi)容比較典型，大家有興趣可以也思考一下。先是樓主提出問題：最近公司一個(gè)項(xiàng)目,是個(gè)門戶網(wǎng)站,需要做性能測(cè)試,根據(jù)項(xiàng)目特點(diǎn)定出了主要測(cè)試項(xiàng)和測(cè)試方案一種是測(cè)試幾個(gè)常用頁面能接受的最大并發(fā)數(shù)(用戶名參數(shù)化,設(shè)置集合點(diǎn)策略)一種是測(cè)試服務(wù)器長

13、時(shí)間壓力下,用戶能否正常操作(用戶名參數(shù)化,迭代運(yùn)行腳本)還有一種則需要測(cè)試服務(wù)器能否接受10萬用戶同時(shí)在線操作,但使用的Loadrunner的license只能支持1萬用戶,請(qǐng)問這時(shí)該如何制定該方案?后面跟著大家的回復(fù)：網(wǎng)友 xingcyx 的回復(fù)：1、找10臺(tái)電腦也沒用，license仍然只支持10000個(gè)。2、找HP支持。當(dāng)然，前提是你有足夠的錢。3、測(cè)到10000用戶并發(fā)。我認(rèn)為，通常情況下10000用戶并發(fā)，支持用戶在線，沒有問題的。網(wǎng)友 jackloo 的回復(fù)：總的來說這一類的性能指標(biāo)對(duì)大多數(shù)軟件來說沒什么實(shí)際意義，更多的是對(duì)硬件的要求。如果是用IIS做應(yīng)用服務(wù)器的話，單臺(tái)可承受的

14、最大并發(fā)數(shù)不可能達(dá)到10萬級(jí)，那就必須要使用集群，通過多臺(tái)機(jī)器做負(fù)載均衡來實(shí)現(xiàn)；如果是用websphere之類的應(yīng)用服務(wù)器的話，單臺(tái)可承受的最大并發(fā)數(shù)可以達(dá)到10萬級(jí)，但為性能考慮還是必須要使用集群，通過多臺(tái)機(jī)器做負(fù)載均衡來實(shí)現(xiàn)；那么，你只要集群的服務(wù)器足夠多，10萬并發(fā)數(shù)當(dāng)然可以達(dá)到了。通常有1個(gè)簡單的計(jì)算方式，1個(gè)連接產(chǎn)生1個(gè)session，每個(gè)session在服務(wù)器上有個(gè)內(nèi)存空間大小的設(shè)置，在NT上是3M，那么10萬并發(fā)就需要300G內(nèi)存，當(dāng)然實(shí)際使用中考慮其他程序也占用內(nèi)存，所以準(zhǔn)備的內(nèi)存數(shù)量要求比這個(gè)還要多一些。還有10萬個(gè)用戶同時(shí)在線，跟10萬個(gè)并發(fā)數(shù)是完全不同的2個(gè)概念。這個(gè)樓上

15、已經(jīng)說了。但如何做這個(gè)轉(zhuǎn)換將10萬個(gè)同時(shí)在線用戶轉(zhuǎn)換成多少個(gè)并發(fā)數(shù)呢？這就必須要有大量的歷史日志信息來支撐了。系統(tǒng)日志需要有同時(shí)在線用戶數(shù)量的日志信息，還需要有用戶操作次數(shù)的日志信息，這2個(gè)數(shù)據(jù)的比例就是你同時(shí)在線用戶轉(zhuǎn)換到并發(fā)數(shù)的比例。另外根據(jù)經(jīng)驗(yàn)統(tǒng)計(jì)，對(duì)于1個(gè)JAVA開發(fā)的WEB系統(tǒng)（別的我沒統(tǒng)計(jì)過，給不出數(shù)據(jù)），一般1臺(tái)雙CPU、2G內(nèi)存的服務(wù)器上可支持的最大并發(fā)數(shù)不超過500個(gè)（這個(gè)狀態(tài)下大部分操作都是超時(shí)報(bào)錯(cuò)而且服務(wù)器很容易宕機(jī)，其實(shí)沒什么實(shí)際意義），可正常使用（單步非大數(shù)據(jù)量操作等待時(shí)間不超過20秒）的最大并發(fā)數(shù)不超過300個(gè)。假設(shè)你的10萬同時(shí)在線用戶轉(zhuǎn)換的并發(fā)數(shù)是9000個(gè)，那

16、么你最少需要這樣的機(jī)器18臺(tái)，建議不少于30臺(tái)。當(dāng)然，你要是買個(gè)大型服務(wù)器，里面裝有200個(gè)CPU、256G的內(nèi)存，千兆光纖帶寬，就算是10萬個(gè)并發(fā)用戶，那速度，也絕對(duì)是嗖嗖的。樓主的回復(fù)：謝謝jackloo!再請(qǐng)問如果我想測(cè)試10000個(gè)用戶同時(shí)在線做常用操作的話(每兩秒加一個(gè)用戶,一直加到10000),對(duì)服務(wù)器的要求有多高?網(wǎng)友 jackloo 的回復(fù)：套用1句經(jīng)典臺(tái)詞“高，實(shí)在是高”呵呵。另外暴寒1下，你的設(shè)置光全部進(jìn)入運(yùn)行狀態(tài)就需要接近6個(gè)小時(shí)。具體的你可以拿1個(gè)系統(tǒng)來壓一下看看，可能會(huì)出現(xiàn)以下情況：1。服務(wù)器宕機(jī)；2。客戶端宕機(jī)；3。從某個(gè)時(shí)間開始服務(wù)器拒絕請(qǐng)求，客戶端上顯示的全是錯(cuò)

17、誤；4。勉強(qiáng)測(cè)試完成，但網(wǎng)絡(luò)堵塞或測(cè)試結(jié)果顯示時(shí)間非常長。假設(shè)客戶端和服務(wù)器之間百兆帶寬，百兆/10000=10K，那每個(gè)用戶只能得到10K，這個(gè)速度接近1個(gè)64K的MODEM上網(wǎng)的速度；另外以上分析全都沒考慮系統(tǒng)的后臺(tái)，比如數(shù)據(jù)庫、中間件等。我從沒遇到你說的這樣的性能需求過，也只好憑感覺隨便掰掰：1。服務(wù)器方面：上面說的那樣的PCSERVER需要50臺(tái)；2。網(wǎng)絡(luò)方面：按每個(gè)用戶50K，那至少5根百兆帶寬獨(dú)享，估計(jì)僅僅網(wǎng)絡(luò)延遲就大概是秒一級(jí)的；3。如果有數(shù)據(jù)庫，至少是ORACLE，最好是SYSBASE，SQLSERVER是肯定頂不住的。數(shù)據(jù)庫服務(wù)器至少需要10臺(tái)4CPU、16G內(nèi)存的機(jī)器；4。

18、如果有CORBA，那至少再準(zhǔn)備10臺(tái)4CPU、16G內(nèi)存的機(jī)器；再加上負(fù)載均衡、防火墻、路由器和各種軟件等，總之沒個(gè)1000萬的資金投入，肯定搞不定。網(wǎng)友 mybasswood 的回復(fù)：如果是10萬用戶的話要看做些什么哈.比如對(duì)于voip來說,假設(shè)有10萬用戶的話,服務(wù)器規(guī)定每個(gè)client至少要在3600秒內(nèi)到服務(wù)器成功報(bào)到一次,否則就被服務(wù)器cancel掉.client是每隔60秒注冊(cè)一次.所以就要推算在3600秒內(nèi),每一個(gè)client至少成功報(bào)到一次是最少的標(biāo)準(zhǔn).要10萬用戶在3600秒內(nèi)被服務(wù)器吃掉才可以-這是最低要求.最高要求是:在60秒內(nèi)所有的10萬用戶去注冊(cè),如果服務(wù)器在60秒可

19、以都吃掉的話,每秒種的平均并發(fā)差不多是3334.最低要求是:在3600秒內(nèi)所有的10用戶去注冊(cè),如果服務(wù)器在3600秒內(nèi)都可以吃掉的話,每秒鐘的平均并發(fā)用戶差不多是60個(gè).還有一過問題是客戶端要在3600秒內(nèi)發(fā)送至少60次,至少有一次成功.再加上這些用戶分布在全球各地的話,這樣數(shù)值應(yīng)該還會(huì)有變化的.下面是偶的看法：給樓主一個(gè)建議吧。你在公司中的測(cè)試環(huán)境是一定的，你需要做得是現(xiàn)在這個(gè)環(huán)境中確認(rèn)一下系統(tǒng)在當(dāng)前環(huán)境下的實(shí)際處理能力。如果還有資源，再做一下可伸縮性的測(cè)試。然后對(duì)測(cè)試結(jié)果進(jìn)行分析，對(duì)系統(tǒng)的處理能力和可伸縮性做一個(gè)描述。當(dāng)然，要在報(bào)告中說明你的測(cè)試環(huán)境。另外一位網(wǎng)友robust 的留言：你

20、的意思是否想用10000個(gè)用戶測(cè)試結(jié)果來推測(cè)一下10萬個(gè)用戶?還是如有些老兄說的,測(cè)試一下什么伸縮性測(cè)試.然后也來個(gè)報(bào)告,無非也是想用1萬個(gè)來推測(cè)10萬個(gè)的情況?(評(píng)注:那樣的話要你做什么性能測(cè)試,只要計(jì)算一下就可以得性能結(jié)果了.)還是如有些老兄說的,這一類的性能指標(biāo)對(duì)大多數(shù)軟件來說沒什么實(shí)際意義，更多的是對(duì)硬件的要求?(評(píng)注:那樣的話要你做什么性能測(cè)試,做什么性能調(diào)優(yōu),只要計(jì)算一下,添加硬件就可以了.)實(shí)際上,實(shí)踐是檢驗(yàn)真理的唯一標(biāo)準(zhǔn)!這句話才是硬道理.只有真實(shí)地測(cè)試過才知道.任何推測(cè)只是推測(cè),并不能反映真實(shí)的情況.至于性能測(cè)試工具,LR只是普及率高(市場占有率高),并不是在性能指標(biāo)上有優(yōu)勢(shì)

21、.世界上比它厲害的工具有不少,舉個(gè)例子siprent通信公司的avalanche2500,大型計(jì)算機(jī)實(shí)驗(yàn)室配備的性能測(cè)試工具.支持錄制/回放,測(cè)試結(jié)果分析等.它可以模擬從數(shù)據(jù)層到應(yīng)用層的協(xié)議,(當(dāng)然也包含http-web),單個(gè)支持100萬并發(fā)連接.拿它也可以測(cè)試100萬級(jí)的并發(fā)性能.又是偶的回復(fù)：樓上的提到的見解不錯(cuò)，不過對(duì)性能測(cè)試的理解有些偏差。先拋開性能測(cè)試工具不談，其實(shí)這個(gè)問題是討論到一個(gè)性能測(cè)試到底該怎么做。簡單舉個(gè)例子，如果你想知道一種新的疫苗對(duì)人的作用，是不是要把所有的地球人全部找來每個(gè)人打一針試試呢？當(dāng)然不是，只能是通過試驗(yàn)和抽樣，然后通過統(tǒng)計(jì)學(xué)的方法來計(jì)算出一個(gè)模型，通過樣本

22、的表現(xiàn)來估算總體的特征。這就是統(tǒng)計(jì)學(xué)研究的領(lǐng)域，。不過請(qǐng)注意，統(tǒng)計(jì)學(xué)所包含的內(nèi)容并不是像樓上的老兄所說的一樣：只要計(jì)算一下就可以得性能結(jié)果了。性能測(cè)試也同樣如此。樓主提到的性能需求應(yīng)該是系統(tǒng)上線以后可能要面臨的壓力，先不討論這個(gè)需求是否準(zhǔn)確和有效，我們先假定它是有效的。那么，既然要驗(yàn)證的是系統(tǒng)在上線以后是否有能力應(yīng)對(duì)10萬用戶同時(shí)在線的情況，那么自然要用生產(chǎn)環(huán)境來測(cè)試。如果有，那么OK，可以作這個(gè)測(cè)試。至于工具，其實(shí)可以由開發(fā)人員幫忙寫一些簡單的腳本負(fù)責(zé)加壓，再通過其他第三方工具收集測(cè)試數(shù)據(jù)就是了。但是如果沒有生產(chǎn)環(huán)境，只有一臺(tái)雙CPU，3G內(nèi)存的2850服務(wù)器，怎么辦？這就好像上面提到的例子?？尚械姆椒ㄊ窃谶@臺(tái)服務(wù)器上使用不同級(jí)別的負(fù)載來進(jìn)行測(cè)試，并根據(jù)測(cè)試數(shù)據(jù)獲得系統(tǒng)在這種環(huán)境下的最佳負(fù)載和最大負(fù)載，并根據(jù)測(cè)試數(shù)據(jù)對(duì)負(fù)載和資源消耗的情況進(jìn)行估算，找到它們之間的關(guān)系。一般來說，大型的門戶網(wǎng)站不會(huì)只用一臺(tái)超級(jí)超