一個真實項目的LoadRunner軟件性能測試的數據分析

一個真實項目的LoadRunner軟件性能測試的數據分析　　

摘要: ezFAS消防監控軟件是同方股份公司開發的一個功能強大的城市火災遠程監控管理平臺，主要面向大型火災監控管理中心如省市、大型廠礦企業、石油、各類區域和行業內部的消防管理部門，為主管部門提供實時報警、視頻監聽、故障檢測、統計分析等功能。

　　ezFAS消防監控軟件是同方股份公司開發的一個功能強大的城市火災遠程監控管理平臺，主要面向大型火災監控管理中心如省市、大型廠礦企業、石油、各類區域和行業內部的消防管理部門，為主管部門提供實時報警、視頻監聽、故障檢測、統計分析等功能。

　　該系統包括報警受理系統，用戶服務系統，信息查詢系統，火警信息終端四部分組成。報警受理系統主要為監控中心提供實時報警，用戶管理，視頻查看，人員考勤，報表生成等各大主要功能。下面就對這套主要的報警受理系統的性能數據進行分析。

　　2 測試環境

　　服務器：

　　CPU 型號：Inter(R) Core(TM)2 Duo T5450

　　主頻：1.66GHZ

　　內存容量：1.00GB

　　操作系統：Microsoft Windows Server 2003 Enterprise Edition SP2

　　客戶端：

　　CPU 型號：Intel Pentium III

　　主頻:930MHZ

　　內存容量：640MB

　　操作系統：Microsoft Windows XP Professional SP2

　　網絡環境：

　　在測試網絡中有且僅有兩臺測試計算機，測試機之間通過1個Hub連接。

　　3 測試場景

　　用戶進入登陸模塊，總共登陸500個用戶，每分鐘登陸10個用戶。用戶點擊“ASE管理”，用戶在查詢的區縣里面選擇“石河子市”然后點擊查找。查找結束后點擊“退出”按鈕，退出系統。

　　4 性能數據分析

　　我們對500個用戶的同時登陸進程，進行每5分鐘增加10個用戶的加壓測試。此次測 試在250分鐘后結束。

　　4.1 Transactions Sunmmary(事務綜述)

　　用戶事務分析是站在用戶角度進行的基礎性能分析。此次測試一共運行的事務數為9690145，成功 968750，失敗250。

　　觀察發現隨著用戶數量的不斷增加，失敗的事務開始出現，并且出現的頻率逐步升高。

　　當程序運行到200個用戶同時登陸時，失敗事務開始出現。由此可以直接判斷出當200個用戶同步登陸時系統運行出現異常。此系統最大承受壓力為200個用戶同步登陸。

　　但考慮到此套系統主要用于省級市的監控，對于最大的省份，監控中心數量不會超過50 個，所有監控中心的用戶同時登陸數量也不會超過100個。此套系統最大承受壓力為200，所以性能已經大大超過要求，并不需要花費時間和精力優化系統的運行穩定性。

　　4.2 Average Transaciton Response Time(事務平均響應時間)

　　事務平均響應時間顯示的是測試場景運行期間的每一秒內事務執行所用的平均時間，通過它可以分析測試場景運行期間系統性能的走向。

　　如果隨著測試時間的變化，系統處理事務的速度開始逐漸變慢就說明應用系統隨著投產時間的變化整體性能將會有下降的趨勢。

　　在這次250分鐘的測試中，事務相應平均時間沒有大幅度的變化，但這不能說明系統就是穩定的，250分鐘的測試時間很短，所以我們針對這個結果單獨進行了5天持續不斷的測試，發現性能也沒有變化。說明整體性能過關。

　　將它與Transactions per Second(每秒通過事務數/TPS)進行對比，來分析事務數目對執行時間的影響。如果當壓力加大時，點擊率/TPS曲線變化緩慢且有了平坦的趨勢，則可能是服務器開始出現瓶頸。但是在這次測試中TPS曲線隨著壓力的加大曲線變化成正比增加，這此臺測試服務器完全能滿足要求。在工程施工中只要服務器配置達到此臺服務器配置即可。

　　*Transactions per Second (每秒通過事務數/TPS):顯示在場景運行的每一秒鐘，每個事物通過、失敗以及挺直的數量，是考察系統性能的一個重要參數。通過它可以確定系統在任何給定時刻的時間事務負載。

　　4.3 Transaction Response Time(Distribution)(事務相應時間分布)

　　“事務相應時間分布”顯示在場景運行過程中，事務執行所用時間的分布，通過它可以了解測試過程中不同相應時間的事物數量。如果我們預先定義了相關事務可以接受的最小和最大事務響應時間，則可以使用此圖確定服務器性能是否在可以接受的范圍呢。

　　此次測試定義了登陸時間<3秒，查詢時間<5秒，退出時間〈2秒。從圖片上看出登陸和退出時間完全符合要求，但是查詢時間隨著用戶的不斷增多以密指數的比例變大，當用戶超過200個同時查詢時，反映時間已經達到10秒以上。不能滿足系統需要。

　　經過對程序的分析發現，查詢時需要調用的表過多，設計太過復雜。將表單的設計簡單化即可解決問題。

　　以前表結構的設計：

　　現在將所有內容統一到一張表格中：

　　經過對程序的修改后再次進行測試，問題已經解決，所有用戶同時查詢時反映時間也在要求之下。

　　4.4 Hits per Second(每秒點擊次數)

　　“每秒點擊次數”是運行場景過程中虛擬用戶每秒向Web服務器提交的HTTP請求數。同uota可以評估虛擬用戶長生的負載量。

　?、畔旅嫖覀儗⑺汀捌骄聞枕憫獣r間”圖比較，來查看點擊次數對事務性能產生的影響。通過對查看“每秒點擊次數”，可以判斷系統是否穩定。

　　4.5 單用戶系統登陸和查詢報警信息資源特性表

　　以上是對于測試性能的一些最基本的數據分析，如果測試性能涉及到SQL Server,我在下列出比較關鍵的幾個數據。

　　5 結論

　　測試結果表明，500個用戶在并發登陸系統，查詢ASE信息，退出系統的響應時間分別不超過2秒和5秒。服務器資源占用情況正常。系統在模擬測試環境中運行穩定，可以通過。

原文轉自：http://www.anti-gravitydesign.com