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

2、ror: timed out Error: Server“ 30 has shut down theconn ecti on prematurely分析：A、應用服務死掉。（小用戶時：程序上的問題。程序上處理數據庫的問題，實際測試中多半是 服務器鏈接的配置問題）B、應用服務沒有死（應用服務參數設置問題）對應的 Apache 和 tomcat 的最大鏈接數需要修改，如果連接時收到 connection refused 消息，說明應提高相應的服務器最大連接的設置，增加幅 度要根據實際情況和服務器硬件的情況來定，建議每次增加25%！C、數據庫的連接( 數據庫啟動的最大連接數(跟硬

3、件的內存有關) )D我們的應用程序spring控制的最大鏈接數太低2. Error: Page download timeout (120 seconds) has expired分析：A、應用服務參數設置太大導致服務器的瓶頸B、頁面中圖片太多C、在程序處理表的時候檢查字段太大多D實際測試時有些資源需要請求外網，而我們的測試環境是局域網環境3. Error “30/Home.do ”分析：A、腳本設計錯誤，造成頁面異常。服務器有響應！B、并發數過大，造成服務器響應延遲。4. Error page “text=xxxxx ”分析：A、腳本設計問題，例如，前一腳本修

4、改了某些內容，造成后面的腳本訪問 異常。B、不確定因素，有時候回放正常的腳本，一放到場景中就出現這樣的錯誤 只能反復修改腳本！二監控指標數據分析1Vusers 數Loadrunner 系統設置的虛擬用戶數目。 Vuser 去實際調用事先制作的腳本 文件中的應用。每個 Vuser 產生響應的操作，所有的操作對服務器形成并發。顏色 比例 度量 圖最小值 圖平均值 圖最大值 圖中間值 圖 SD1 Run 0.0 21.25 44 41 21.276在實際測試中， Vusers 可以根據實際情況的需要，在測試過程中增加或者 減少。2最大并發用戶數：顏色 比例 度量 最小值 平均值 最大值 SD100

5、Apache CPU使用情況(Apache):100.777 0.852 0.93 0.0430.01 已發送 KB/ 秒(Apache):106 1430.371 2689.333 327.9240.1 點擊次數 / 秒(Apache):10 0.333 114.352 533.667 40.201應用系統在當前環境下能承受的最大并發用戶數。在方案運行中，如果出現了大批用戶的業務操作失敗，或出現了服務器 shutdown 的情況，則說明在當前環境下，系統承受不了當前并發用戶的負載壓 力，那么最大并發用戶數就是前一個沒有出現這種現象的

6、并發用戶數。從上圖可以看出：在測試運行到 4個小時左右的時候， apache 的點擊數 /秒 開始迅速增加！3 業務操作響應時間：使用 “事務性能摘要 ”圖，可以確定在方案執行期間響應時間過長的事務。顏色 比例 度量1 最小值1 平均值1 最大值分析事務的響應情況， 要每次詳細分析， 目前還只能觀察到響應時間過長的事務！4每秒點擊數負載測試期間每秒內 Vuser 在 Web 服務器上點擊的次數。 可根據點擊次數來估算 Vuser 生成的負 載數。顏色 比例 度量 圖最小值 平均值 圖最大值 圖中間值 圖 SD1 點擊次數 69.908 105.736 130.244 103.666 12.18

7、6從圖中不難看出，在 4 小時的時候，點技數明顯增高。和 apache 的每秒點擊數增大的時間相吻合！5吞吐量負載測試期間 Web 服務器上的吞吐量 （字節 ）。吞吐量表示在任何指定秒內 Vuser 從服務器接收到的 數據量。此圖可估計 Vuser 生成的負載量 （服務器吞吐量 ）。顏色 比例 度量 圖最小值 平均值 圖最大值 圖中間值 圖 SD1 Throughput 1257502.795 1375591.372 1525865.047 1372743.691 49130.473同樣，從圖中可以看出，在 4 個小時的時候， web 服務器的吞吐量開始增高。在圖中還可以看到吞吐 量的走勢圖，

8、從開始到進行到 4 個小時反彈之前呈降低的趨勢，這是因為系統在初期調用的資源都是直接 來之服務器，運行一段時間后系統的部分資源來自緩存。6下載組件大小每個頁面的組件大小，且包括組件的標頭的大小！頁面組件大小的分析表格比較復雜，實際分析中可以通過 loadrunner 的報告分析工具來分析。頁面組 件大小分析主要是找到頁面中比較龐大的組件，如果其影響到了頁面的下載速度，則要想辦法將其改小！7 Apache 資源顯示 APACHE web 服務器上的資源摘要。前面已經提到過以并發點擊數為主。顏色 比例 度量 最小值 平均值 最大值 SD100 Apache CPU 使用情況 (Apache):17

9、10 0.777 0.852 0.93 0.0430.01 已發送 KB/ 秒 (Apache):10 6 1430.371 2689.333 327.9240.1 點擊次數 /秒(Apache):10 0.333 114.352 533.667 40.201三服務器資源監控指標：(目前通過 top 監察)內存：Linux 資源監控中指標內存頁交換速率( Paging rate )，如果該值偶爾走高，表明當時有線程競爭內 存。如果持續很高，則內存可能是瓶頸。也可能是內存訪問命中率低。實際測試中，當并發點擊數出現突然劇增前后，內存的 PR

10、值則居高 25 不下。說明目前測試的系統 中內存存在瓶頸！內存資源成為系統性能的瓶頸的征兆 :很高的換頁率 (high pageout rate);進程進入不活動狀態 ;交換區所有磁盤的活動次數可高 ;可高的全局系統 CPU 利用率 ;內存不夠出錯 (out of memory errors)處理器：Linux 資源監控中指標 CPU 占用率持續超過 80%(對該值的要求， 根據具體應用和機器配置而要求不 同，有資料表明 95 )，表明瓶頸是 CPU 。實際測試中， 當并發點技數出現突然增加前后， cpu 的占用率持續保持在 86以上！說明，目前系統用應用的 cpu 也是測試的瓶頸！CPU 資

11、源成為系統性能的瓶頸的征兆 :很慢的響應時間 (slow response time)CPU 空閑時間為零 (zero percent idle CPU)過高的用戶占用 CPU 時間 (high percent user CPU)過高的系統占用 CPU時間(high percent system CPU)長時間的有很長的運行進程隊歹(large run queue size sustained over time)四數據庫服務器：數據庫服務器目前測試觀察，當web服務器點擊率增大時，觀察 mysql數據庫的最大連接數，仍未超過系統設置的最大連接數。所以，暫時未發現數據庫的瓶頸！五.結論以上報告

12、分析中的數據、圖標均來自同一次測試。是在平時測試中挑岀的一次現象比較明顯，比較利 于觀察的作為分析案例。根據以上綜合分析，當前測試環境下，當應用系統產生最大533.667的并發壓力。平均負載壓力114.352。根據分析，用戶在 4個小時的時候，并發數迅速增加前后的值在400左右！分析結果跟實際測試的硬件環境以及測試腳本有一定關系。同時，測試服務器的硬件配置和實際服務器的配置還有一定的差 距！轉一份在51testing 上的討論如何測試一個門戶網站是否可以支持10萬用戶同時在線？Posted on 2006-11-16 01:21Jackei閱讀(6074) 評論(5) 編輯 收藏 網摘 所屬分

13、類：04.軟件性能測試.這個帖子的內容比較典型，大家有興趣可以也思考一下。先是樓主提岀問題:最近公司一個項目，是個門戶網站，需要做性能測試，根據項目特點定出了主要測試項和測一種是測試幾個常用頁面能接受的最大并發數(用戶名參數化，設置集合點策略)一種是測試服務器長時間壓力下，用戶能否正常操作(用戶名參數化，迭代運行腳本)還有一種則需要測試服務器能否接受10萬用戶同時在線操作，但使用的Loadrunner的Iicense只能支持1萬用戶，請問這時該如何制定該方案？后面跟著大家的回復：網友 xingcyx 的回復：1、 找10臺電腦也沒用，license仍然只支持10000個。2、找HP支持。當然，

14、前提是你有足夠的錢。3、 測到10000用戶并發。我認為，通常情況下10000用戶并發，支持100000 用戶 在線，沒有問題的。網友jackloo 的回復:總的來說這一類的性能指標對大多數軟件來說沒什么實際意義，更多的是對硬件的要求。如果是用IIS做應用服務器的話，單臺可承受的最大并發數不可能達到10萬級，那就必須要使用集群，通過多臺機器做負載均衡來實現；如果是用websphere 之類的應用服務器的話，單臺可承受的最大并發數可以達到10萬級，但為性能考慮還是必須要使用集群，通過多臺機器做負載均衡來實現；那么，你只要集群的服務器足夠多，10萬并發數當然可以達到了。通常有1個簡單的計算方式，1

15、個連接產生1個session ，每個session在服務器上有個 內存空間大小的設置，在 NT上是3M，那么10萬并發就需要300G內存，當然實際使用 中考慮其他程序也占用內存，所以準備的內存數量要求比這個還要多一些。還有10萬個用戶同時在線，跟 10萬個并發數是完全不同的 2個概念。這個樓上已經說 了。但如何做這個轉換將 10萬個同時在線用戶轉換成多少個并發數呢？這就必須要有大量的歷史日志信息來支撐了。系統日志需要有同時在線用戶數量的日志信息，還需要有用戶操作次數的日志信息，這2個數據的比例就是你同時在線用戶轉換到并發數的比例。另外根據經驗統計，對于1個JAVA開發的WEB系統（別的我沒統計

16、過，給不出數據），一般1臺雙CPU、2G內存的服務器上可支持的最大并發數不超過500個（這個狀態下大部分操作都是超時報錯而且服務器很容易宕機，其實沒什么實際意義），可正常使用（單步非大數據量操作等待時間不超過20秒）的最大并發數不超過 300個。假設你的10萬同時在線用戶轉換的并發數是9000個，那么你最少需要這樣的機器18臺，建議不少于 30臺。當然，你要是買個大型服務器，里面裝有200個CPU、256G的內存，千兆光纖帶寬，就算是10萬個并發用戶，那速度，也絕對是嗖嗖的。樓主的回復:謝謝 jackloo !再請問如果我想測試10000 個用戶同時在線做常用操作的話（每兩秒加一個用戶，一直加

17、到10000）,對服務器的要求有多高 ？網友jackloo的回復：套用1句經典臺詞 高，實在是高”呵呵。另外暴寒1下，你的設置光全部進入運行狀態就需要接近6個小時。具體的你可以拿1個系統來壓一下看看，可能會出現以下情況：1。服務器宕機；2。客戶端宕機；3。從某個時間開始服務器拒絕請求，客戶端上顯示的全是錯誤；4。勉強測試完成，但網絡堵塞或測試結果顯示時間非常長。假設客戶端和服務器之間百兆帶寬，百兆/10000=10K，那每個用戶只能得到 10K，這個速度接近1個64K的MODEM上網的速度；另外以上分析全都沒考慮系統的后臺，比如數據庫、中間件等。我從沒遇到你說的這樣的性能需求過，也只好憑感覺隨

18、便掰掰：1。 服務器方面：上面說的那樣的PC SERVER需要50臺；2。 網絡方面：按每個用戶50K，那至少5根百兆帶寬獨享，估計僅僅網絡延遲就大概是 秒一級的；3。如果有數據庫，至少是 ORACLE，最好是 SYSBASE , SQL SERVER 是肯定頂不住的。數據庫服務器至少需要10臺4CPU、16G內存的機器；4。如果有CORBA，那至少再準備10臺4CPU、16G內存的機器；再加上負載均衡、防火墻、路由器和各種軟件等，總之沒個1000萬的資金投入，肯定搞不定。網友 mybasswood 的回復：如果是10萬用戶的話要看做些什么哈比如對于voip來說，假設有10萬用戶的話，服務器規

19、定每個 client至少要在3600秒內 到服務器成功報到一次，否則就被服務器cancel掉.client是每隔60秒注冊一次.所以就要推算在 3600秒內,每一個client至少成功報到一次是最少的標準.要10萬用戶在3600秒內被服務器吃掉才可以 -這是最低要求.最高要求是：在60秒內所有的10萬用戶去注冊，如果服務器在60秒可以都吃掉的話，每 秒種的平均并發差不多是3334.最低要求是：在3600秒內所有的10用戶去注冊，如果服務器在3600秒內都可以吃掉的 話，每秒鐘的平均并發用戶差不多是 60個.還有一過問題是客戶端要在 3600秒內發送至少 60次,至少有一次成功.再加上這些用戶分

20、布在全球各地的話 ，這樣數值應該還會有變化的.下面是偶的看法：給樓主一個建議吧。你在公司中的測試環境是一定的，你需要做得是現在這個環境中確認一下系統在當前環境下的實際處理能力。如果還有資源，再做一下可伸縮性的測試。然后對測試結果進行分析，對系統的處理能力和可伸縮性做一個描述。當然，要在報告中說明你的測試環境。另外一位網友robust的留言：你的意思是否想用 10000個用戶測試結果來推測一下10萬個用戶？還是如有些老兄說的，測試一下什么伸縮性測試.然后也來個報告，無非也是想用1萬個來 推測10萬個的情況?（評注:那樣的話要你做什么性能測試，只要計算一下就可以得性能結果了）還是如有些老兄說的，這

21、一類的性能指標對大多數軟件來說沒什么實際意義，更多的是對 硬件的要求?（評注:那樣的話要你做什么性能測試，做什么性能調優，只要計算一下，添加硬件就可以了 .）實際上,實踐是檢驗真理的唯一標準!這句話才是硬道理.只有真實地測試過才知道.任何推測只是推測，并不能反映真實的情況.至于性能測試工具丄R只是普及率高（市場占有率高）,并不是在性能指標上有優勢.世界上 比它厲害的工具有不少，舉個例子siprent通信公司的avalanche2500,大型計算機實驗室配備的性能測試工具.支持錄制/回放,測試結果分析等.它可以模擬從數據層到應用層的協議 （當然也包含http-web）,單個支持100萬并發連接.

22、拿它也可以測試100萬級的并發性能.又是偶的回復:樓上的提到的見解不錯，不過對性能測試的理解有些偏差。先拋開性能測試工具不談，其實這個問題是討論到一個性能測試到底該怎么做。簡單舉個例子，如果你想知道一種新的疫苗對人的作用，是不是要把所有的地球人全部找 來每個人打一針試試呢？當然不是，只能是通過試驗和抽樣，然后通過統計學的方法來計算出一個模型，通過樣本的表現來估算總體的特征。這就是統計學研究的領域，。不過請注意，統計學所包含的內容并不是像樓上的老兄所說的一樣：只要計算一下就可以得性能結果了。性能測試也同樣如此。樓主提到的性能需求應該是系統上線以后可能要面臨的壓力，先不討論這個需求是否準確和有效，我們先假定它是有效的。那么，既然要驗證的是系統在上線以后是否有能力應對10萬用戶同時在線的情況，那么自然要用生產環境來測試。如果有，那么0K ,可以作這個測試。至于工具，其實可以由開發人員幫忙寫一些簡單的腳本負責加壓，再通過其他第三方工具收集測試數據就是了。但是如果沒有生產環境，只有一臺雙CPU，3G內存的2850服務器，怎么辦？這就好像上面提到的例子。可行的方法是在這臺服務器上使用不同級別的負載來進行測試，并根據測試數據獲得系統在這種環境下的最佳負載和最大負載，并根據測試數據對負載和資源消耗的情況進行估算，找到它們之間的關系。一般來說，大型的門戶網站不會