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

1、LoadRunner壓力測試結(jié)果分析探討分析原則：1. 具體問題具體分析（這是由于不同的應(yīng)用系統(tǒng)，不同的測試目的，不同的性能關(guān)注點）2. 查找瓶頸時按以下順序，由易到難。服務(wù)器硬件瓶頸 網(wǎng)絡(luò)瓶頸（對局域網(wǎng)，可以不考慮） 服務(wù)器操作系統(tǒng)瓶頸（參數(shù)配置） 中間件瓶頸（參數(shù)配置，數(shù)據(jù)庫，web服務(wù)器等） 應(yīng)用瓶頸（SQL語句、數(shù)據(jù)庫設(shè)計、業(yè)務(wù)邏輯、算法等）分析的信息來源：1. 根據(jù)場景運行過程中的錯誤提示信息2. 根據(jù)測試結(jié)果收集到的監(jiān)控指標數(shù)據(jù)一錯誤提示分析分析實例：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ù)據(jù)庫的問題，實際測試中多半是服務(wù)器鏈接的配置問題）B、應(yīng)用服務(wù)沒有死（應(yīng)用服務(wù)參數(shù)設(shè)置問題）對應(yīng)的Apache和tomcat的最大鏈接數(shù)需要修改，如果連接時收到connection refused消息，說明應(yīng)提高相應(yīng)的服務(wù)器最大連接的設(shè)置，增加幅度要根據(jù)實際情況和服務(wù)器硬件的情況來定，建議每次增加25%！C、數(shù)據(jù)庫的連接(數(shù)據(jù)庫啟動的最大連接數(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、在程序處理表的時候檢查字段太大多D、實際測試時有些資源需要請求外網(wǎng)，而我們的測試環(huán)境是局域網(wǎng)環(huán)境3. Error “30/Home.do.”分析：A、腳本設(shè)計錯誤，造成頁面異常。服務(wù)器有響應(yīng)！B、并發(fā)數(shù)過大，造成服務(wù)器響應(yīng)延遲。4. Error page “text=xxxxx”分析：A、腳本設(shè)計問題，例如，前一腳本修改了某些內(nèi)容，

4、造成后面的腳本訪問異常。B、不確定因素，有時候回放正常的腳本，一放到場景中就出現(xiàn)這樣的錯誤。只能反復(fù)修改腳本！二監(jiān)控指標數(shù)據(jù)分析1Vusers數(shù)Loadrunner 系統(tǒng)設(shè)置的虛擬用戶數(shù)目。Vuser去實際調(diào)用事先制作的腳本文件中的應(yīng)用。每個Vuser產(chǎn)生響應(yīng)的操作，所有的操作對服務(wù)器形成并發(fā)。顏色 比例 度量 圖最小值 圖平均值 圖最大值 圖中間值 圖SD1 Run 0.0 21.25 44 41 21.276在實際測試中，Vusers可以根據(jù)實際情況的需要，在測試過程中增加或者減少。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 點擊次數(shù)/秒(Apache):10 0.333 114.352 533.667 40.201應(yīng)用系統(tǒng)在當前環(huán)境下能承受的最大并發(fā)用戶數(shù)。在方案運行中，如果出現(xiàn)了大批用戶的業(yè)務(wù)操作失敗，或出現(xiàn)了服務(wù)器shutdown的情況，則說明在當前環(huán)境下，系統(tǒng)承受不了當前并發(fā)用戶的負載壓力，那么最大并發(fā)用戶數(shù)就是前一個沒有出現(xiàn)這種現(xiàn)象的并發(fā)用戶數(shù)。從上圖可以看出：在測試運行到4

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

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

8、組件大小，且包括組件的標頭的大小！頁面組件大小的分析表格比較復(fù)雜，實際分析中可以通過loadrunner的報告分析工具來分析。頁面組件大小分析主要是找到頁面中比較龐大的組件，如果其影響到了頁面的下載速度，則要想辦法將其改小！7Apache資源顯示APACHE web服務(wù)器上的資源摘要。前面已經(jīng)提到過以并發(fā)點擊數(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 點擊次數(shù)/秒(Apache):10 0.333 114.352 533.667 40.201三服務(wù)器資源監(jiān)控指標：（目前通過top監(jiān)察）內(nèi)存：Linux資源監(jiān)控中指標內(nèi)存頁交換速率（Paging rate），如果該值偶爾走高，表明當時有線程競爭內(nèi)存。如果持續(xù)很高，則內(nèi)存可能是瓶頸。也可能是內(nèi)存訪問命中率低。實際測試中，當并發(fā)點擊數(shù)出現(xiàn)突然劇增前后，內(nèi)存的PR 值則居高25不下。說明目前測試的系統(tǒng)中內(nèi)存存在瓶頸！內(nèi)存資源成為系統(tǒng)性能的瓶頸的征兆:很高的換頁率(high pageout rate);進程進入不活動狀態(tài);交換區(qū)所有磁盤的活動次數(shù)可高;可高的全

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

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

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

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

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

15、已經(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ù)器很容易宕機，其實沒什么實際意義），可正常使用（單步非大數(shù)據(jù)量操作等待時間不超過20秒）的最大并發(fā)數(shù)不超過300個。假設(shè)你的10萬同時在線用戶轉(zhuǎn)換的并發(fā)數(shù)是9000個，那

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

17、誤；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，最好是SYSBASE，SQLSERVER是肯定頂不住的。數(shù)據(jù)庫服務(wù)器至少需要10臺4CPU、16G內(nèi)存的機器；4。

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

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

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

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

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