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

1、.：.；LoadRunner壓力測試結(jié)果分析討論分析原那么：1. 詳細問題詳細分析這是由于不同的運用系統(tǒng)，不同的HYPERLINK javascript:; t _self測試目的，不同的性能關(guān)注點2. 查找瓶頸時按以下順序，由易到難。效力器硬件瓶頸 網(wǎng)絡(luò)瓶頸對局域網(wǎng)，可以不思索 效力器HYPERLINK javascript:; t _self操作系統(tǒng)瓶頸參數(shù)配置 中間件瓶頸參數(shù)配置，HYPERLINK javascript:; t _self數(shù)據(jù)庫，HYPERLINK javascript:; t _selfweb效力器等 運用瓶頸HYPERLINK javascript:; t _sel

2、fSQL語句、數(shù)據(jù)庫設(shè)計、業(yè)務(wù)邏輯、算法等分析的信息來源：1. 根據(jù)場景運轉(zhuǎn)過程中的錯誤提示信息2. 根據(jù)測試結(jié)果搜集到的監(jiān)控目的數(shù)據(jù)一錯誤提示分析分析實例：1Error: Failed to connect to server “30: 10060 ConnectionError: timed out Error: Server “30 has shut down the connection prematurely分析：A、運用效力死掉。小用戶時：程序上的問題。程序上處置數(shù)據(jù)庫的問題，實踐測試中多半是效力器鏈接的配置問題B、運用效力沒有死運用效力參數(shù)設(shè)置問題對應(yīng)的Apache和tomcat

3、的最大鏈接數(shù)需求修正，假設(shè)銜接時收到connection refused音訊，闡明應(yīng)提高相應(yīng)的效力器最大銜接的設(shè)置，添加幅度要根據(jù)實踐情況和效力器硬件的情況來定，建議每次添加25%！C、數(shù)據(jù)庫的銜接(數(shù)據(jù)庫啟動的最大銜接數(shù)跟硬件的內(nèi)存有關(guān))D、我們的運用程序spring控制的最大鏈接數(shù)太低2. Error: Page download timeout (120 seconds) has expired分析：A、運用效力參數(shù)設(shè)置太大導(dǎo)致效力器的瓶頸B、頁面中圖片太多C、在程序處置表的時候檢查字段太大多D、實踐測試時有些資源需求懇求外網(wǎng)，而我們的測試環(huán)境是局域網(wǎng)環(huán)境3. Error “30/Hom

4、e.do分析：A、腳本設(shè)計錯誤，呵斥頁面異常。效力器有呼應(yīng)！B、并發(fā)數(shù)過大，呵斥效力器呼應(yīng)延遲。4. Error page “text=xxxxx分析：A、腳本設(shè)計問題，例如，前一腳本修正了某些內(nèi)容，呵斥后面的腳本訪問異常。B、不確定要素，有時候回放正常的腳本，一放到場景中就出現(xiàn)這樣的錯誤。只能反復(fù)修正腳本！二監(jiān)控目的數(shù)據(jù)分析1Vusers數(shù)Loadrunner 系統(tǒng)設(shè)置的虛擬用戶數(shù)目。Vuser去實踐調(diào)用事先制造的腳本文件中的運用。每個Vuser產(chǎn)生呼應(yīng)的操作，一切的操作對效力器構(gòu)成并發(fā)。顏色 比例 度量 圖最小值 圖平均值 圖最大值 圖中間值 圖SD1 Run 0.0 21.25 44 4

5、1 21.276在實踐測試中，Vusers可以根據(jù)實踐情況的需求，在測試過程中添加或者減少。2最大并發(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 327.9240.1 點擊次數(shù)/秒(Apache):10 0.333 114.352 533.667 40.201運用系統(tǒng)在當(dāng)前環(huán)境下能接受的最大并發(fā)用戶數(shù)。在方案運轉(zhuǎn)中，假設(shè)出現(xiàn)了大批用戶的業(yè)務(wù)操作失敗，或出現(xiàn)了效力器shutdown的情況，那么

6、闡明在當(dāng)前環(huán)境下，系統(tǒng)接受不了當(dāng)前并發(fā)用戶的負載壓力，那么最大并發(fā)用戶數(shù)就是前一個沒有出現(xiàn)這種景象的并發(fā)用戶數(shù)。從上圖可以看出：在測試運轉(zhuǎn)到4個小時左右的時候，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 效力器上點擊的次數(shù)。可根據(jù)點擊次數(shù)來估算 Vuser 生成的負載數(shù)。顏色 比例 度量 圖最小值 平均值 圖最大值 圖中間值 圖SD1 點擊次數(shù)

7、69.908 105.736 130.244 103.666 12.186從圖中不難看出，在4小時的時候，點技數(shù)明顯增高。和apache的每秒點擊數(shù)增大的時間相吻合！5吞吐量負載測試期間 Web 效力器上的吞吐量(字節(jié))。吞吐量表示在任何指定秒內(nèi) Vuser 從效力器接納到的數(shù)據(jù)量。此圖可估計 Vuser 生成的負載量(效力器吞吐量)。顏色 比例 度量 圖最小值 平均值 圖最大值 圖中間值 圖SD1 Throughput 1257502.795 5591.372 1525865.047 2743.691 49130.473同樣，從圖中可以看出，在4個小時的時候，web效力器的吞吐量開場增高。在

8、圖中還可以看到吞吐量的走勢圖，從開場到進展到4個小時反彈之前呈降低的趨勢，這是由于系統(tǒng)在初期調(diào)用的資源都是直接來之效力器，運轉(zhuǎn)一段時間后系統(tǒng)的部分資源緩存。6下載組件大小每個頁面的組件大小，且包括組件的標頭的大??！頁面組件大小的分析表格比較復(fù)雜，實踐分析中可以經(jīng)過loadrunner的報告分析工具來分析。頁面組件大小分析主要是找到頁面中比較龐大的組件，假設(shè)其影響到了頁面的下載速度，那么要想方法將其改??！7Apache資源顯示APACHE web效力器上的資源摘要。前面曾經(jīng)提到過以并發(fā)點擊數(shù)為主。顏色 比例 度量 最小值 平均值 最大值 SD100 Apache CPU 運用情況(Apache)

9、: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三效力器資源監(jiān)控目的：目前經(jīng)過top監(jiān)察內(nèi)存：Linux資源監(jiān)控中目的內(nèi)存頁交換速率Paging rate，假設(shè)該值偶爾走高，闡明當(dāng)時有線程競爭內(nèi)存。假設(shè)繼續(xù)很高，那么內(nèi)存能夠是瓶頸。也能夠是內(nèi)存訪問命中率低。實踐測試中，當(dāng)并發(fā)點擊數(shù)出現(xiàn)忽然劇增前后，內(nèi)存的PR 值那么居高25不下。闡明目前測試的系統(tǒng)中內(nèi)存存在瓶頸！內(nèi)存資源成為系統(tǒng)性能的瓶頸

10、的征兆:很高的換頁率(high pageout rate);進程進入不活動形狀;交換區(qū)一切磁盤的活動次數(shù)可高;可高的全局系統(tǒng)CPU利用率;內(nèi)存不夠出錯(out of memory errors)處置器：Linux資源監(jiān)控中目的CPU占用率繼續(xù)超越80%對該值的要求，根據(jù)詳細運用和機器配置而要求不同，有資料闡明95，闡明瓶頸是CPU。實踐測試中，當(dāng)并發(fā)點技數(shù)出現(xiàn)忽然添加前后，cpu的占用率繼續(xù)堅持在86以上！闡明，目前系統(tǒng)用運用的cpu也是測試的瓶頸！CPU資源成為系統(tǒng)性能的瓶頸的征兆:很慢的呼應(yīng)時間(slow response time)CPU空閑時間為零(zero percent idle

11、CPU)過高的用戶占用CPU時間(high percent user CPU)過高的系統(tǒng)占用CPU時間(high percent system CPU)長時間的有很長的運轉(zhuǎn)進程隊列(large run queue size sustained over time)四數(shù)據(jù)庫效力器：數(shù)據(jù)庫效力器目前測試察看，當(dāng)web效力器點擊率增大時，察看mysql數(shù)據(jù)庫的最大銜接數(shù)，仍未超越系統(tǒng)設(shè)置的最大銜接數(shù)。所以，暫時未發(fā)現(xiàn)數(shù)據(jù)庫的瓶頸！五結(jié)論以上報告分析中的數(shù)據(jù)、圖標均同一次測試。是在平常測試中挑出的一次景象比較明顯，比較利于察看的作為分析案例。根據(jù)以上綜合分析，當(dāng)前測試環(huán)境下，當(dāng)運用系統(tǒng)產(chǎn)生最大533.

12、667的并發(fā)壓力。平均負載壓力114.352。根據(jù)分析，用戶在4個小時的時候，并發(fā)數(shù)迅速添加前后的值在400左右！分析結(jié)果跟實踐測試的硬件環(huán)境以及測試腳本有一定關(guān)系。同時，測試效力器的硬件配置和實踐效力器的配置還有一定的差距！HYPERLINK cnblogs/jackei/archive/2006/11/16/561846.html轉(zhuǎn)一份在 51testing 上的討論如何測試一個門戶網(wǎng)站能否可以支持10萬用戶同時在線？ Posted on 2006-11-16 01:21 HYPERLINK cnblogs/jackei/Jackei 閱讀(6074) HYPERLINK cnblogs/

13、jackei/archive/2006/11/16/561846.html l commentform評論(5) HYPERLINK cnblogs/jackei/admin/EditPosts.aspx?postid=561846編輯 HYPERLINK cnblogs/jackei/AddToFavorite.aspx?id=561846收藏 HYPERLINK cnblogs/jackei/archive/2006/11/16/561846.html網(wǎng)摘 所屬分類: HYPERLINK cnblogs/jackei/category/32808.html04.軟件性能測試 這個帖子的內(nèi)容

14、比較典型，大家有興趣可以也思索一下。先是樓主提出問題：最近公司一個工程,是個門戶網(wǎng)站,需求做性能測試,根據(jù)工程特點定出了主要測試項和測試方案一種是測試幾個常用頁面能接受的最大并發(fā)數(shù)(用戶名參數(shù)化,設(shè)置集合點戰(zhàn)略)一種是測試效力器長時間壓力下,用戶能否正常操作(用戶名參數(shù)化,迭代運轉(zhuǎn)腳本)還有一種那么需求測試效力器能否接受10萬用戶同時在線操作,但運用的Loadrunner的license只能支持1萬用戶,請問這時該如何制定該方案?后面跟著大家的回復(fù)：網(wǎng)友 HYPERLINK bbs.51testing/profile-uid-1274.html t _blankxingcyx 的回復(fù)：1、找1

15、0臺電腦也沒用，license依然只支持10000個。2、找HP支持。當(dāng)然，前提是他有足夠的錢。3、測到10000用戶并發(fā)。我以為，通常情況下10000用戶并發(fā)，支持100000用戶在線，沒有問題的。網(wǎng)友 HYPERLINK bbs.51testing/profile-uid-24546.html t _blankjackloo 的回復(fù)：總的來說這一類的性能目的對大多數(shù)軟件來說沒什么實踐意義，更多的是對硬件的要求。假設(shè)是用IIS做運用效力器的話，單臺可接受的最大并發(fā)數(shù)不能夠到達10萬級，那就必需求運用集群，經(jīng)過多臺機器做負載平衡來實現(xiàn)；假設(shè)是用websphere之類的運用效力器的話，單臺可接受

16、的最大并發(fā)數(shù)可以到達10萬級，但為性能思索還是必需求運用集群，經(jīng)過多臺機器做負載平衡來實現(xiàn)；那么，他只需集群的效力器足夠多，10萬并發(fā)數(shù)當(dāng)然可以到達了。通常有1個簡單的計算方式，1個銜接產(chǎn)生1個session，每個session在效力器上有個內(nèi)存空間大小的設(shè)置，在NT上是3M，那么10萬并發(fā)就需求300G內(nèi)存，當(dāng)然實踐運用中思索其他程序也占用內(nèi)存，所以預(yù)備的內(nèi)存數(shù)量要求比這個還要多一些。還有10萬個用戶同時在線，跟10萬個并發(fā)數(shù)是完全不同的2個概念。這個樓上曾經(jīng)說了。但如何做這個轉(zhuǎn)換將10萬個同時在線用戶轉(zhuǎn)換成多少個并發(fā)數(shù)呢？這就必需求有大量的歷史日志信息來支撐了。系統(tǒng)日志需求有同時在線用戶數(shù)

17、量的日志信息，還需求有用戶操作次數(shù)的日志信息，這2個數(shù)據(jù)的比例就是他同時在線用戶轉(zhuǎn)換到并發(fā)數(shù)的比例。另外根據(jù)閱歷統(tǒng)計，對于1個JAVA開發(fā)的WEB系統(tǒng)別的我沒統(tǒng)計過，給不出數(shù)據(jù)，普通1臺雙CPU、2G內(nèi)存的效力器上可支持的最大并發(fā)數(shù)不超越500個這個形狀下大部分操作都是超時報錯而且效力器很容易宕機，其實沒什么實踐意義，可正常運用單步非大數(shù)據(jù)量操作等待時間不超越20秒的最大并發(fā)數(shù)不超越300個。假設(shè)他的10萬同時在線用戶轉(zhuǎn)換的并發(fā)數(shù)是9000個，那么他最少需求這樣的機器18臺，建議不少于30臺。當(dāng)然，他要是買個大型效力器，里面裝有200個CPU、256G的內(nèi)存，千兆光纖帶寬，就算是10萬個并發(fā)用

18、戶，那速度，也絕對是嗖嗖的。樓主的回復(fù)：謝謝jackloo!再請問假設(shè)我想測試10000個用戶同時在線做常用操作的話(每兩秒加一個用戶,不斷加到10000),對效力器的要求有多高?網(wǎng)友 HYPERLINK bbs.51testing/profile-uid-24546.html t _blankjackloo 的回復(fù)：套用1句經(jīng)典臺詞“高，真實是高呵呵。另外暴寒1下，他的設(shè)置光全部進入運轉(zhuǎn)形狀就需求接近6個小時。詳細的他可以拿1個系統(tǒng)來壓一下看看，能夠會出現(xiàn)以下情況：1。效力器宕機；2?？蛻舳隋礄C；3。從某個時間開場效力器回絕懇求，客戶端上顯示的全是錯誤；4。勉強測試完成，但網(wǎng)絡(luò)堵塞或測試結(jié)果

19、顯示時間非常長。假設(shè)客戶端和效力器之間百兆帶寬，百兆/10000=10K，那每個用戶只能得到10K，這個速度接近1個64K的MODEM上網(wǎng)的速度；另外以上分析全都沒思索系統(tǒng)的后臺，比如數(shù)據(jù)庫、中間件等。我從沒遇到他說的這樣的性能需求過，也只好憑覺得隨意掰掰：1。效力器方面：上面說的那樣的PCSERVER需求50臺；2。網(wǎng)絡(luò)方面：按每個用戶50K，那至少5根百兆帶寬獨享，估計僅僅網(wǎng)絡(luò)延遲就大約是秒一級的；3。假設(shè)有數(shù)據(jù)庫，至少是ORACLE，最好是SYSBASE，SQLSERVER是一定頂不住的。數(shù)據(jù)庫效力器至少需求10臺4CPU、16G內(nèi)存的機器；4。假設(shè)有CORBA，那至少再預(yù)備10臺4CP

20、U、16G內(nèi)存的機器；再加上負載平衡、防火墻、路由器和各種軟件等，總之沒個1000萬的資金投入，一定搞不定。網(wǎng)友 HYPERLINK bbs.51testing/profile-uid-673.html t _blankmybasswood 的回復(fù)：假設(shè)是10萬用戶的話要看做些什么哈.比如對于voip來說,假設(shè)有10萬用戶的話,效力器規(guī)定每個client至少要在3600秒內(nèi)到效力器勝利報到一次,否那么就被效力器cancel掉.client是每隔60秒注冊一次.所以就要推算在3600秒內(nèi),每一個client至少勝利報到一次是最少的規(guī)范.要10萬用戶在3600秒內(nèi)被效力器吃掉才可以這是最低要求.最

21、高要求是:在60秒內(nèi)一切的10萬用戶去注冊,假設(shè)效力器在60秒可以都吃掉的話,每秒種的平均并發(fā)差不多是3334.最低要求是:在3600秒內(nèi)一切的10用戶去注冊,假設(shè)效力器在3600秒內(nèi)都可以吃掉的話,每秒鐘的平均并發(fā)用戶差不多是60個.還有一過問題是客戶端要在3600秒內(nèi)發(fā)送至少60次,至少有一次勝利.再加上這些用戶分布在全球各地的話,這樣數(shù)值應(yīng)該還會有變化的.下面是偶的看法：給樓主一個建議吧。他在公司中的測試環(huán)境是一定的，他需求做得是如今這個環(huán)境中確認一下系統(tǒng)在當(dāng)前環(huán)境下的實踐處置才干。假設(shè)還有資源，再做一下可伸縮性的測試。然后對測試結(jié)果進展分析，對系統(tǒng)的處置才干和可伸縮性做一個描畫。當(dāng)然，

22、要在報告中闡明他的測試環(huán)境。另外一位網(wǎng)友HYPERLINK bbs.51testing/profile-uid-9430.html t _blankrobust 的留言：他的意思能否想用10000個用戶測試結(jié)果來推測一下10萬個用戶?還是如有些老兄說的,測試一下什么伸縮性測試.然后也來個報告,無非也是想用1萬個來推測10萬個的情況?(評注:那樣的話要他做什么性能測試,只需計算一下就可以得性能結(jié)果了.)還是如有些老兄說的,這一類的性能目的對大多數(shù)軟件來說沒什么實踐意義，更多的是對硬件的要求?(評注:那樣的話要他做什么性能測試,做什么性能調(diào)優(yōu),只需計算一下,添加硬件就可以了.)實踐上,實際是檢驗真

23、理的獨一規(guī)范!這句話才是硬道理.只需真實地測試過才知道.任何推測只是推測,并不能反映真實的情況.至于性能測試工具,LR只是普及率高(市場占有率高),并不是在性能目的上有優(yōu)勢.世界上比它厲害的工具有不少,舉個例子siprent通訊公司的avalanche2500,大型計算機實驗室配備的性能測試工具.支持錄制/回放,測試結(jié)果分析等.它可以模擬從數(shù)據(jù)層到運用層的協(xié)議,(當(dāng)然也包含http-web),單個支持100萬并發(fā)銜接.拿它也可以測試100萬級的并發(fā)性能.又是偶的回復(fù)：樓上的提到的見解不錯，不過對性能測試的了解有些偏向。先拋開性能測試工具不談，其實這個問題是討論到一個性能測試究竟該怎樣做。簡單舉

24、個例子，假設(shè)他想知道一種新的疫苗對人的作用，是不是要把一切的地球人全部找來每個人打一針試試呢？當(dāng)然不是，只能是經(jīng)過實驗和抽樣，然后經(jīng)過統(tǒng)計學(xué)的方法來計算出一個模型，經(jīng)過樣本的表現(xiàn)來估算總體的特征。這就是統(tǒng)計學(xué)研討的領(lǐng)域，。不過請留意，統(tǒng)計學(xué)所包含的內(nèi)容并不是像樓上的老兄所說的一樣：只需計算一下就可以得性能結(jié)果了。性能測試也同樣如此。樓主提到的性能需求應(yīng)該是系統(tǒng)上線以后能夠要面臨的壓力，先不討論這個需求能否準確和有效，我們先假定它是有效的。那么，既然要驗證的是系統(tǒng)在上線以后能否有才干應(yīng)對10萬用戶同時在線的情況，那么自然要用消費環(huán)境來測試。假設(shè)有，那么OK，可以作這個測試。至于工具，其實可以由開發(fā)人員協(xié)助 寫一些簡單的腳本擔(dān)任加壓，再經(jīng)過其他第三方工具搜集測試數(shù)據(jù)就是了。但是假設(shè)沒有消費環(huán)境，只需一臺雙CPU，3G內(nèi)存的2850效力器，怎樣辦？這就好似上面提到的例子?？尚械姆椒ㄊ窃谶@臺效力器上運用不同級別的負載來進展測試，并根據(jù)測試數(shù)據(jù)獲得系統(tǒng)在這種