性能測試分析報告案例

1、密級：秘密*公司*管理系統(tǒng)性能測試分析報告(V2.0)北京*軟件技術開發(fā)有限公司2008年12月01日標題*公司*管理系統(tǒng)性能測試分析報告創(chuàng)建日期2008-12-01打印日期文件名存放目錄所有者作者張三修訂記錄日期描述作者對結論進行細化李四文檔審核/審批此文檔需如下審核。姓名職務/職稱簽名簽名日期*公司*管理系統(tǒng)性能測試分析報告目錄1 測試背景11.1 測試目標11.2 測試時間11.3 測試地點11.4 測試人員12 測試方法簡介 13 測試環(huán)境33.1 被測系統(tǒng)33.1.1 硬件環(huán)境33.1.2 數(shù)據(jù)庫環(huán)境43.1.3 軟件環(huán)境43.2 測試系統(tǒng)43.2.1 測試環(huán)境搭建43.2.2 測試

2、軟件44 測試設計54.1 模擬用戶數(shù)54.2 測試模型建立55 測試結果分析65.1 業(yè)務場景一（無基礎數(shù)據(jù)）梯度壓力測試分析 65.1.1 平均響應時間梯度對比 65.1.2 系統(tǒng)資源利用率75.1.3 系統(tǒng)處理能力85.2 業(yè)務場景一對比測試分析 85.2.1 平均響應時間對比 85.2.2 處理能力對比95.2.3 資源利用率對比圖 95.3 系統(tǒng)穩(wěn)定性測試105.4 有、無合同場景對比測試 115.4.1 響應時間分析 115.4.2 處理能力對比圖125.4.3 資源利用率對比圖 135.5 業(yè)務場景二調優(yōu)對比測試 135.5.1 第一次調優(yōu) 145.5.2 第二次調優(yōu) 155.5

3、.3 第三次調優(yōu) 166 測試結論176.1 業(yè)務場景一（無合同） 176.2 業(yè)務場景二（有合同） 176.3 穩(wěn)定性187 調優(yōu)建議188 簽字確認191測試背景1.1測試目標對*公司*管理系統(tǒng)的開具發(fā)票功能進行性能測試，客觀、公正評估系統(tǒng)的性能現(xiàn)狀。1、開發(fā)正確、有效的性能測試腳本，模擬企業(yè)用戶開具發(fā)票操作行為，作為測試有效 實施的基礎；2、 通過性能測試，客觀、公正評估在當前測試環(huán)境下，被測系統(tǒng)的各項性能指標表現(xiàn)；3、驗證被測系統(tǒng)的業(yè)務處理能力是否能夠滿足在業(yè)務高峰期的性能要求，為被測系統(tǒng) 上線提供參考依據(jù)。如不滿足，對性能瓶頸進行定位分析，提供性能調優(yōu)建議。1.2測試時間測試自200

4、8年11月20日啟動，至12月01日測試執(zhí)行結束。1.3測試地點*大廈*座*層1.4測試人員單位姓名備注* 公司*北京#公司*2測試方法簡介壓力測試采用業(yè)界成熟的自動化性能測試工具，通過創(chuàng)建壓力測試程序、構建壓力測試模型，對被測試系統(tǒng)實施自動化壓力測試，最后形成壓力測試結果分析報告。1）壓力測試實施模型：通過自動化測試工具模擬最終用戶向服務器發(fā)起業(yè)務請求，進行性能測試。通過測試工公開第10頁具對測試過程中系統(tǒng)各點進行監(jiān)控告供分析使用被測系統(tǒng)性能監(jiān)控器虛擬用戶生成器控制器測試環(huán)境準備系統(tǒng)性能壓力測試環(huán)境要求與生產系統(tǒng)的軟硬件環(huán)境保持并具有相同規(guī)模的業(yè)壓力模型定義用例選取是性典型的交易和業(yè)務流程1

5、)用戶操作使用頻繁2)對系統(tǒng)性能影響較大3)性能測試壓力符合業(yè)務系統(tǒng)實際的實際交易發(fā)生比例4)循環(huán)測試數(shù)據(jù)準備測試數(shù)據(jù)要求盡量模擬真實業(yè)務數(shù)據(jù)公開Web服務器2.模擬大量的真實用戶生 成壓力3.監(jiān)控器實時捕獲系統(tǒng)的性能 狀態(tài)2）壓力測試實施基本流程間隔，并發(fā)間隔，用戶加載和減壓時間根據(jù)系統(tǒng)基準測試結果進行判斷和設置。每一次測試結束后工具自動采集測試結果并生成原始報務數(shù)據(jù)，并保證軟件版本與生產環(huán)境保持能測試壓力模型設計的首要任務。用例選取的原則是1.Controller起到調度壓力測 試并管理監(jiān)控器實際執(zhí)行場景的設置盡量模擬實際業(yè)務進行，運行時長，操作間隔（思考時間）第2頁而且具有一定可重用性。

6、能貫穿各相關系統(tǒng)，保應用服務器數(shù)據(jù)庫服務器*公司*管理系統(tǒng)性能測試分析報告此次性能測試的用例選擇，按照*公司提供的業(yè)務數(shù)據(jù)進行分析抽取14.測試結果被搜集及 保存起來供分析5.產生性能分析報告*公司*管理系統(tǒng)性能測試分析報告證業(yè)務流程的順暢正確。具體的數(shù)據(jù)類型和數(shù)據(jù)量需要根據(jù)選擇的交易類別或性能測試場景 設置而定。此外性能測試會產生大量的虛擬用戶，需要消耗大量的測試數(shù)據(jù)。其數(shù)量直接關乎測試結果。測試中所需的基本數(shù)據(jù)類型為：系統(tǒng)用戶數(shù)據(jù)：登陸系統(tǒng)使用的用戶名-口令等，數(shù)量與虛擬用戶數(shù)一致。業(yè)務數(shù)據(jù)：每個虛擬用戶模擬真實用戶進行操作時使用到的數(shù)據(jù)。輔助數(shù)據(jù)：為保證業(yè)務操作的正常進行而設置的基本信息

7、資料。測試程序開發(fā)：利用在歷史數(shù)據(jù)收集步驟中所獲得的典型用戶的系統(tǒng)訪問模式，做為測試程序開發(fā)的依據(jù)。該測試程序應該覆蓋典型用戶的系統(tǒng)訪問模式所涉及的操作。腳本的開發(fā)是利用LoadRunner Vugen進行腳本錄制，開發(fā)，參數(shù)化，調試的過程。測試執(zhí)行：測試準備階段完畢后，確保測試環(huán)境、測試程序、測試過程、測試數(shù)據(jù)，且均已驗證通 過后，然后在指定的時間內可對系統(tǒng)施實性能測試，性能測試執(zhí)行分為兩個階段：1、性能基準測試：系統(tǒng)在輕負載環(huán)境下，模擬各業(yè)務的單用戶交易，評估當前系統(tǒng)的 性能表現(xiàn)，并作為后續(xù)壓力測試的性能比較基準；2、單交易負載測試：3、負載壓力測試：仿真現(xiàn)實，模擬大批量并發(fā)業(yè)務交易，評估

8、系統(tǒng)在高負載情況下系統(tǒng)的性能表現(xiàn)。測試結果分析報告：壓力測試結果經過確認有效后，將匯總壓力測試結果，形成最終的性能測試分析報告。3測試環(huán)境3.1被測系統(tǒng)3.1.1硬件環(huán)境系統(tǒng)IP地址所在主機配置備注應用服務器192.168.3.13CPU Xeon MPX4600 2.6GHzWin2003 Server內存硬盤8G200G 7200 轉192.168.3.15CPUXeon MPX4600 2.6GHzWin2003 Server數(shù)據(jù)庫服務器內存8G硬盤500G 7200 轉3.1.2數(shù)據(jù)庫環(huán)境使用生成的6800萬條數(shù)據(jù)。3.1.3軟件環(huán)境類型應用及版本號備注應用服務器Weblogic8.1

9、數(shù)據(jù)庫Oracle 9i3.2測試系統(tǒng)3.2.1測試環(huán)境搭建測試機配置：類型數(shù)量（臺）IP配置備注控制臺1192.168.3.129Intel E4600 2.4GHzWin2003 Server內存2G/硬盤400G 7200轉負載發(fā)9192.168.3.130Intel E4600 2.4GHzWin2003 Server生器192.168.3.138內存1G/硬盤400G 7200轉3.2.2測試軟件采用Mercury In teractive公司的LoadRu nner測試及分析軟件作為測試工具。LoadRunner 簡介：LoadRunner是一種預測系統(tǒng)行為和性能的工業(yè)標準級負載測

10、試工具。在LoadRunner的幫助下，用戶可以以模擬上千萬用戶實施并發(fā)負載及實時性能監(jiān)測的方式來確認和查找問 題。LoadRunner能夠對整個企業(yè)架構進行測試，它通過模擬實際用戶的操作行為和實行實 時性能監(jiān)測，來幫助用戶更快的查找和發(fā)現(xiàn)問題。此外，LoadRunner能支持廣泛的協(xié)議和技術，可以為用戶的特殊環(huán)境提供特殊的解決方案。本次測試采用的LoadRunner版本為9.0。4測試設計4.1模擬用戶數(shù)依據(jù)系統(tǒng)目前的業(yè)務量以及未來業(yè)務量增長，對當前系統(tǒng)分別按3000、4500、6000用戶進行壓力測試，以評估系統(tǒng)在不同壓力梯度情況下的性能表現(xiàn)。4.2測試模型建立此次性能測試的業(yè)務選擇，應覆

11、蓋各性能關鍵業(yè)務，并通過*公司、北京*公司雙方協(xié)商選取被測業(yè)務。根據(jù)協(xié)商選定如下業(yè)務進行性能測試：開具發(fā)票以此基礎上定義測試執(zhí)行壓力模型：在混合業(yè)務場景壓力梯度測試過程中，分別按 3000、4500、6000用戶進行壓力測試， 在各個壓力測試過程中保持測試場景和調度測試的完全一致，使結果具有很好的可比性。壓力測試執(zhí)行場景描述如下：1、模擬用戶數(shù)：3000、4500、60002、Pacing： 120 秒；3、當所有用戶加載完畢后連續(xù)運行 15分鐘；4、用戶調度策略：每1秒啟動30個虛擬用戶。業(yè)務場景序號交易業(yè)務配比執(zhí)行 時間操作 間隔1開具發(fā)票100%15分鐘120秒業(yè)務場景二序號交易業(yè)務配比

12、執(zhí)行 時間操作 間隔1開具發(fā)票（無合同）85%15分鐘120秒2開具發(fā)票（有合同）15%說明:按照以上場景設置，可估算出模擬用戶數(shù)與每小時業(yè)務量的對應關系如下:模擬用戶數(shù)300045006000每小時業(yè)務量900001350001800005測試結果分析說明：術語解釋（事務）LoadRunner中定義，為一個流程中某個環(huán)節(jié)的稱謂，一個流程可稱為 一個大的事務，在這個大的交易中包含許多的小的事務。響應時間一LoadRunner中衡量流程中各個事務性能的最佳手段，計算的是端到端的時間，說的通俗一點，從點擊應用中的某個控件，到從數(shù)據(jù)庫返回數(shù)據(jù)到客戶端，整個過程都被計算在事務的響應時間內。場景Load

13、Runner中專門術語。它是所有測試資源包括測試腳本、運行設置、運 行用戶數(shù)等的集合。在這個場景中，可以定義并發(fā)用戶的數(shù)目， 定義要運行的腳本， 或者說運行的流程類型。 在一個場景中，可以是單個流程，也可以是多個流程的混 合。虛擬用戶一LoadRunner中特定術語，為模擬現(xiàn)實中的實際用戶，測試軟件使用虛 擬用戶代替真實的用戶。5.1業(yè)務場景一（無基礎數(shù)據(jù)）梯度壓力測試分析5.1.1平均響應時間梯度對比下圖是不同用戶數(shù)下各事務的平均響應時間隨用戶數(shù)變化的曲線：公開第10頁*公司*管理系統(tǒng)性能測試分析報告一登錄開具發(fā)票*錄入并開具事務3000用戶4500用戶6000用戶登錄0.561.3122.

14、14開具發(fā)票0.240.872.08錄入并開具0.431.0982.70平均響應時間分析：從上圖中可以看出，各操作的響應時間隨著用戶數(shù)的增加呈上升趨勢，但都沒有超過5秒，在可接受范圍內。5.1.2系統(tǒng)資源利用率cpu利用率（%* cpu利用率（%CPU利用率分析：在上圖中我們可以看出 3000用戶、4500用戶及6000用戶時，CPU利用率均在正常范圍 內，系統(tǒng)表現(xiàn)良好。公開第10頁*公司*管理系統(tǒng)性能測試分析報告5.1.3系統(tǒng)處理能力TPS公開第10頁*公司*管理系統(tǒng)性能測試分析報告公開第10頁*公司*管理系統(tǒng)性能測試分析報告系統(tǒng)處理能力分析：可以看出，在無基礎數(shù)據(jù)的情況下，系統(tǒng)處理能力隨用

15、戶數(shù)的增加呈線性上升趨勢，即系統(tǒng)無性能瓶頸，6000用戶時系統(tǒng)處理能力達到每小時173880筆，滿足并超出客戶提出的4小時20萬張發(fā)票的處理能力。5.2業(yè)務場景一對比測試分析序號用戶數(shù)每小時業(yè)務量基礎數(shù)據(jù)量16000180000無26000126000大于1800萬5.2.1平均響應時間對比下圖是不同壓力情況下，有基礎數(shù)據(jù)與無基礎數(shù)據(jù)各操作響應時間對比圖:響應時間對比圖4500用戶（無基礎數(shù)據(jù)） 4500用戶（有基礎數(shù)據(jù)） 1 6000用戶（無基礎數(shù)據(jù)）6000用戶（有基礎數(shù)據(jù)）1614121086420登錄開具發(fā)票錄入并開具平均響應時間分析：同樣壓力的情況下，在無基礎數(shù)據(jù)的情況下，響應時間均

16、小于5秒。當基礎數(shù)據(jù)量在1800萬的時候，6000用戶壓力下響應時間大幅度提高，超過客戶所提出5秒之內的要求。5.2.2處理能力對比下圖是相同壓力情況下，有基礎數(shù)據(jù)與無基礎數(shù)據(jù)系統(tǒng)的處理能力對比。TPS寸比圖6000用戶（無基礎數(shù)據(jù)）6000用戶（有基礎數(shù)據(jù)）處理能力分析：在有基礎數(shù)據(jù)的情況下， 單從處理能力看，依然可以滿足客戶所提出的要求，但與之前的無基礎數(shù)據(jù)的處理能力比較發(fā)現(xiàn)，基礎數(shù)據(jù)的存在是對處理能力有較大影響。5.2.3資源利用率對比圖下圖是相同壓力情況下，有基礎數(shù)據(jù)與無基礎數(shù)據(jù)各事務資源利用率對比圖:CP利用率對比圖CPU利用率分析：相同壓力下，因有基礎數(shù)據(jù)情況下響應時間變長，系統(tǒng)處

17、理能力下降，CPU利用率也隨之下降，這說明系統(tǒng)瓶頸出現(xiàn)在了其他方面。5.3系統(tǒng)穩(wěn)定性測試在系統(tǒng)測試過程中，我們發(fā)現(xiàn)WebLogic的JVM可用內存逐漸減少，下圖是在WebLogic監(jiān)控臺所監(jiān)控到的情況：公開第10頁*公司*管理系統(tǒng)性能測試分析報告公開第10頁*公司*管理系統(tǒng)性能測試分析報告JVM堆中當前可用的內存量仔節(jié)卜為了驗證確認此現(xiàn)象，進行了4500用戶6個小時的測試，當測試執(zhí)行到1小時左右,WebLogic JVM基本已無內存可用，如下圖所示：U公開第10頁*公司*管理系統(tǒng)性能測試分析報告被占用內存無法釋放， 導致被測系統(tǒng)在長時間運行后響應時間明顯上升，處理能力明顯下降，如下圖所示：Ti

18、iirkScictlois R囪咅po*倍自 1 mi*0GD8DG170Q2S00:3400:4200:51Elapsed scenants time hh：mm00:5§m：i6公開第10頁*公司*管理系統(tǒng)性能測試分析報告公開第10頁*公司*管理系統(tǒng)性能測試分析報告分析：用戶在登錄時，系統(tǒng)會自動生成一個sessio n,并占用部分內存，而這個 session的過期時間設置為2小時，按照用戶習慣分析，當用戶使用直接關閉IE窗口退出系統(tǒng)的方式退出， 這個session是不釋放的，并繼續(xù)占用內存。測試過程中沒有做退出操作，導致大量用戶 session不釋放。根據(jù)上圖顯示，40分鐘時性能

19、開始下降，此時在線用戶數(shù)約為 37.5*60*40=90000。解決方法：開發(fā)人員修改程序，點擊重新登錄時清除sessi on,并在測試過程中，完成開具發(fā)票操作后就點擊重新登錄。重新執(zhí)行測試后，此現(xiàn)象消失。5.4有、無合同場景對比測試在測試過程中，用戶提出部分用戶需要在開具發(fā)票是選擇合同，因此設計以下場景進行測試。序號交易業(yè)務配比執(zhí)行時間1開具發(fā)票（無合同）85%15分鐘2開具發(fā)票（有合同）15%5.4.1響應時間分析在4500用戶壓力下，各操作響應時間如下：業(yè)務操作平均響應時間（秒）有合同一登錄6.07有合同 開具發(fā)票37.83有合同錄入并開具6.38有合同退出3.85有合同 選擇合同34.

20、96無合同一登錄6.27無合同 開具發(fā)票4.45無合同錄入并開具6.18無合同退出3.84說明:此時有合同的開具發(fā)票、 選擇合同操作的響應時間已遠遠超過5秒，其它大部分操作響應時間也超過了 5秒。5.4.2處理能力對比圖下圖是無合同4500用戶與有合同4500用戶情況下系統(tǒng)處理能力對比圖：TPS寸比圖分析：此時系統(tǒng)處理能力仍然滿足 4小時20萬張發(fā)票的要求，但因響應時間過長，認為系統(tǒng) 性能不滿足要求。公開第10頁*公司*管理系統(tǒng)性能測試分析報告5.4.3資源利用率對比圖CP利用率對比圖35資源利用率分析：因響應時間過長，出現(xiàn)大量的隊列等待，導致CPU利用率下降。5.5業(yè)務場景二調優(yōu)對比測試現(xiàn)象

21、：有合同“開具發(fā)票”、“選擇合同”操作的響應時間過長。通過數(shù)據(jù)庫監(jiān)控可以看到，數(shù)據(jù)庫的讀操作過于頻繁，db file sequential read等待事件占總等待時間的 92%以上。分析：經過對系統(tǒng)的監(jiān)控，分析得出幾點對系統(tǒng)性能可能造成影響的原因：1、業(yè)務邏輯a）在進入開具發(fā)票頁面時，系統(tǒng)就加載了全部合同信息，導致“開具發(fā)票”操作響應 時間過長；b）查詢合同信息業(yè)務邏輯有問題，導致“選擇合同”操作響應時間過長；從數(shù)據(jù)庫監(jiān)控中看到，以下兩個SQL的Disk Reads最大：SELECT * FROM HI_BARGAIN WHERE SKZZH=:1 AND BG_STATE=' 正常

22、'SELECT IV_AMOUNT FROM HI_INVOICE WHERE BG_CODE=:1 AND （IV_STA TE='正常or IV_STATE='沖紅'）AND IV_STA TE_2='正常經開發(fā)人員確認，這兩個SQL是查詢合同信息使用的 SQL2、系統(tǒng)參數(shù)a）WebLogic線程數(shù)設置過??；b）Oracle 的 shared pool、buffer cache設置過小。我們對各原因分別進行優(yōu)化后進行測試，最終進行了以下調整：1、調整 shard pool 為 104MB2、調整 buffer cache 為 504MB3、調整查詢合

23、同信息業(yè)務邏輯4、修改weblogic線程數(shù)為150調優(yōu)結果見以下分析。5.5.1第一次調優(yōu)首先修改業(yè)務邏輯，在進入開具發(fā)票頁面時不加載合同信息。然后修改數(shù)據(jù)庫參數(shù)，修改 shard pool 為 104M、修改 buffer cache 為 504M。F圖是4500用戶調優(yōu)前后響應時間對比圖:事務名稱平均響應時間（調優(yōu)前）平均響應時間（調優(yōu)后）合同_登錄6.071.2合同_開具發(fā)票37.831.283合同_錄入并開具6.381.378合同_退出3.850.232合同_選擇合同34.960.483開票_登錄6.271.215開票 開具發(fā)票4.450.568開票 錄入并開具6.181.492開票

24、_退岀3.840.269公開第10頁*公司*管理系統(tǒng)性能測試分析報告4500用尸響應時間對比圖I_I|_LI_|-J L , lL ._.l L,rL,l L,rL, 4500用戶（調優(yōu)前）4500用戶（調優(yōu)后）0505050504 3 3 2 2 11岀退* 具刃 開 票錄 發(fā)具/- 錄登_同合擇選f J合 岸口合合 rfr前合公開第10頁*公司*管理系統(tǒng)性能測試分析報告公開第10頁*公司*管理系統(tǒng)性能測試分析報告在圖中我們可以看出調優(yōu)前后，在相同壓力的情況下，響應時間大幅度下降。調優(yōu)效果 明顯，已滿足響應時間小于 5秒的業(yè)務要求。此時系統(tǒng)處理能力也有明顯的提升。40353025201510

25、50系統(tǒng)處理能力 TPS；14500用戶（調優(yōu)前）4500用戶（調優(yōu)后）5.5.2第二次調優(yōu)由于此時 WebLogic線程經常出現(xiàn)隊列，因此將 WebLogic線程最大值由100調整為150。調整后系統(tǒng)處理能力由36.004上升為37.394。但由于此時系統(tǒng)處理能力已接近場景設計最大值，因此效果不明顯，需要進行一次6000用戶的對比測試。I 4500用戶I 6000用 戶系統(tǒng)處理能力 TPS6000用戶時，響應時間明顯變長，部分操作已超過5秒，而系統(tǒng)處理能力也有明顯的下降，因此系統(tǒng)仍然存在性能瓶頸。5.5.3第三次調優(yōu)此時主要的優(yōu)化方向為優(yōu)化業(yè)務邏輯，因此測試人員提出建議，將查詢合同信息的兩個SQL合并為一個SQL,這樣能夠減少大量的查詢次數(shù)，降低數(shù)據(jù)庫壓力。開發(fā)人員將此業(yè)務邏輯優(yōu)化后，進行了一次6000用戶的對比測試，結果如下：公開第10頁*公司*管理系統(tǒng)性能測試分析報告B 6000用戶（調優(yōu)前） -6000用戶（調優(yōu)后）系統(tǒng)處理能力6000用戶（調優(yōu)前）6000用戶（調優(yōu)后） TPS可以看出，調整業(yè)務邏輯后，各操作響應時間大幅度縮短，系統(tǒng)處理能力有了明顯提升。此時系統(tǒng)處理能力達到每小時164876筆。6測試結論6.1業(yè)務場景一（無合同）1、 系統(tǒng)在測試硬件、無基礎數(shù)據(jù)的情況下，系統(tǒng)處理能力達到每小時173880筆開發(fā)票業(yè)務，滿足客戶