性能測試分析報告案例（DOC X頁）

1、密級：秘密北京*軟件技術開發(fā)有限公司2008年12月01日*公司*管理系統(tǒng)性能測試分析報告（v2.0）*公司*管理系統(tǒng)性能測試分析報告文檔信息標題*公司*管理系統(tǒng)性能測試分析報告創(chuàng)建日期2008-12-01打印日期文件名存放目錄所有者作者張三修訂記錄日期 描述作者對結論進行細化李四文檔審核/審批此文檔需如下審核。姓名職務/職稱簽名簽名日期公開第 19 頁目 錄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第三次調優(yōu)166測試結論176.1業(yè)務場景一（無合同）176

3、.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 測試時間測試自2008年11月20日啟動，至12月01日測試執(zhí)行結束。1.3 測試地點*大廈*座*層1.

4、4 測試人員單位姓名備注*公司*北京#公司*2 測試方法簡介壓力測試采用業(yè)界成熟的自動化性能測試工具，通過創(chuàng)建壓力測試程序、構建壓力測試模型，對被測試系統(tǒng)實施自動化壓力測試，最后形成壓力測試結果分析報告。1）壓力測試實施模型：通過自動化測試工具模擬最終用戶向服務器發(fā)起業(yè)務請求，進行性能測試。通過測試工具對測試過程中系統(tǒng)各點進行監(jiān)控，每一次測試結束后工具自動采集測試結果并生成原始報告供分析使用。2）壓力測試實施基本流程：l 測試環(huán)境準備系統(tǒng)性能壓力測試環(huán)境要求與生產(chǎn)系統(tǒng)的軟、硬件環(huán)境保持一致，并具有相同規(guī)模的業(yè)務數(shù)據(jù)，并保證軟件版本與生產(chǎn)環(huán)境保持一致。l 壓力模型定義：此次性能測試的用例選擇，按

5、照海泰方圓提供的業(yè)務數(shù)據(jù)進行分析抽取，用例選取是性能測試壓力模型設計的首要任務。用例選取的原則是：1) 典型的交易和業(yè)務流程2) 用戶操作使用頻繁3) 對系統(tǒng)性能影響較大4) 性能測試壓力符合業(yè)務系統(tǒng)實際的實際交易發(fā)生比例實際執(zhí)行場景的設置盡量模擬實際業(yè)務進行，運行時長，操作間隔（思考時間），循環(huán)間隔，并發(fā)間隔，用戶加載和減壓時間根據(jù)系統(tǒng)基準測試結果進行判斷和設置。l 測試數(shù)據(jù)準備：測試數(shù)據(jù)要求盡量模擬真實業(yè)務數(shù)據(jù)，而且具有一定可重用性。能貫穿各相關系統(tǒng)，保證業(yè)務流程的順暢正確。具體的數(shù)據(jù)類型和數(shù)據(jù)量需要根據(jù)選擇的交易類別或性能測試場景設置而定。此外性能測試會產(chǎn)生大量的虛擬用戶，需要消耗大量的

6、測試數(shù)據(jù)。其數(shù)量直接關乎測試結果。測試中所需的基本數(shù)據(jù)類型為：u 系統(tǒng)用戶數(shù)據(jù)：登陸系統(tǒng)使用的用戶名-口令等，數(shù)量與虛擬用戶數(shù)一致。u 業(yè)務數(shù)據(jù)：每個虛擬用戶模擬真實用戶進行操作時使用到的數(shù)據(jù)。u 輔助數(shù)據(jù)：為保證業(yè)務操作的正常進行而設置的基本信息資料。l 測試程序開發(fā)：利用在歷史數(shù)據(jù)收集步驟中所獲得的典型用戶的系統(tǒng)訪問模式，做為測試程序開發(fā)的依據(jù)。該測試程序應該覆蓋典型用戶的系統(tǒng)訪問模式所涉及的操作。腳本的開發(fā)是利用loadrunner vugen進行腳本錄制，開發(fā)，參數(shù)化，調試的過程。l 測試執(zhí)行：測試準備階段完畢后，確保測試環(huán)境、測試程序、測試過程、測試數(shù)據(jù)，且均已驗證通過后，然后在指定

7、的時間內可對系統(tǒng)施實性能測試，性能測試執(zhí)行分為兩個階段：1、 性能基準測試：系統(tǒng)在輕負載環(huán)境下，模擬各業(yè)務的單用戶交易，評估當前系統(tǒng)的性能表現(xiàn)，并作為后續(xù)壓力測試的性能比較基準；2、 單交易負載測試：3、 負載壓力測試：仿真現(xiàn)實，模擬大批量并發(fā)業(yè)務交易，評估系統(tǒng)在高負載情況下系統(tǒng)的性能表現(xiàn)。l 測試結果分析報告：壓力測試結果經(jīng)過確認有效后，將匯總壓力測試結果，形成最終的性能測試分析報告。3 測試環(huán)境3.1 被測系統(tǒng)3.1.1 硬件環(huán)境系統(tǒng)ip地址所在主機配置備注應用服務器192.168.3.13cpu：xeon mp x4600 2.6ghz內存8g硬盤200g 7200轉win2003 se

8、rver數(shù)據(jù)庫服務器192.168.3.15cpu：xeon mp x4600 2.6ghz內存8g硬盤500g 7200轉win2003 server3.1.2 數(shù)據(jù)庫環(huán)境使用生成的6800萬條數(shù)據(jù)。3.1.3 軟件環(huán)境類型應用及版本號備注應用服務器weblogic8.1數(shù)據(jù)庫oracle 9i3.2 測試系統(tǒng)3.2.1 測試環(huán)境搭建測試機配置：類型數(shù)量（臺）ip配置備注控制臺1192.168.3.129intel e4600 2.4ghz內存2g/硬盤400g 7200轉win2003 server負載發(fā)生器9192.168.3.130192.168.3.138intel e4600 2.

9、4ghz內存1g/硬盤400g 7200轉win2003 server3.2.2 測試軟件采用mercury interactive公司的loadrunner測試及分析軟件作為測試工具。loadrunner簡介：loadrunner是一種預測系統(tǒng)行為和性能的工業(yè)標準級負載測試工具。在loadrunner的幫助下，用戶可以以模擬上千萬用戶實施并發(fā)負載及實時性能監(jiān)測的方式來確認和查找問題。loadrunner 能夠對整個企業(yè)架構進行測試，它通過模擬實際用戶的操作行為和實行實時性能監(jiān)測，來幫助用戶更快的查找和發(fā)現(xiàn)問題。此外，loadrunner 能支持廣泛的協(xié)議和技術，可以為用戶的特殊環(huán)境提供特殊的

10、解決方案。本次測試采用的loadrunner版本為9.0。4 測試設計4.1 模擬用戶數(shù)依據(jù)系統(tǒng)目前的業(yè)務量以及未來業(yè)務量增長，對當前系統(tǒng)分別按3000、4500、6000用戶進行壓力測試，以評估系統(tǒng)在不同壓力梯度情況下的性能表現(xiàn)。4.2 測試模型建立此次性能測試的業(yè)務選擇，應覆蓋各性能關鍵業(yè)務，并通過海泰方圓、北京行所志雙方協(xié)商選取被測業(yè)務。根據(jù)協(xié)商選定如下業(yè)務進行性能測試： 開具發(fā)票以此基礎上定義測試執(zhí)行壓力模型：在混合業(yè)務場景壓力梯度測試過程中，分別按3000、4500、6000用戶進行壓力測試，在各個壓力測試過程中保持測試場景和調度測試的完全一致，使結果具有很好的可比性。壓力測試執(zhí)行場

11、景描述如下：1、 模擬用戶數(shù)：3000、4500、60002、 pacing：120秒；3、 當所有用戶加載完畢后連續(xù)運行15分鐘；4、 用戶調度策略：每1秒啟動30個虛擬用戶。業(yè)務場景一序號交易業(yè)務配比執(zhí)行時間操作間隔1開具發(fā)票100%15分鐘120秒業(yè)務場景二序號交易業(yè)務配比執(zhí)行時間操作間隔1開具發(fā)票（無合同）85%15分鐘120秒2開具發(fā)票（有合同）15%說明：按照以上場景設置，可估算出模擬用戶數(shù)與每小時業(yè)務量的對應關系如下：模擬用戶數(shù)300045006000每小時業(yè)務量900001350001800005 測試結果分析說明：術語解釋 （事務） loadrunner中定義，為一個流程中某

12、個環(huán)節(jié)的稱謂，一個流程可稱為一個大的事務，在這個大的交易中包含許多的小的事務。 響應時間 loadrunner中衡量流程中各個事務性能的最佳手段，計算的是端到端的時間，說的通俗一點，從點擊應用中的某個控件，到從數(shù)據(jù)庫返回數(shù)據(jù)到客戶端，整個過程都被計算在事務的響應時間內。 場景 loadrunner中專門術語。它是所有測試資源包括測試腳本、運行設置、運行用戶數(shù)等的集合。在這個場景中，可以定義并發(fā)用戶的數(shù)目，定義要運行的腳本，或者說運行的流程類型。在一個場景中，可以是單個流程，也可以是多個流程的混合。 虛擬用戶 loadrunner中特定術語，為模擬現(xiàn)實中的實際用戶，測試軟件使用虛擬用戶代替真實的

13、用戶。5.1 業(yè)務場景一（無基礎數(shù)據(jù)）梯度壓力測試分析5.1.1 平均響應時間梯度對比下圖是不同用戶數(shù)下各事務的平均響應時間隨用戶數(shù)變化的曲線：事務3000用戶4500用戶6000用戶登錄0.561.3122.14 開具發(fā)票0.240.872.08 錄入并開具0.431.0982.70 平均響應時間分析：從上圖中可以看出，各操作的響應時間隨著用戶數(shù)的增加呈上升趨勢，但都沒有超過5秒，在可接受范圍內。5.1.2 系統(tǒng)資源利用率cpu利用率分析：在上圖中我們可以看出3000用戶、4500用戶及6000用戶時，cpu利用率均在正常范圍內，系統(tǒng)表現(xiàn)良好。5.1.3 系統(tǒng)處理能力系統(tǒng)處理能力分析：可以看

14、出，在無基礎數(shù)據(jù)的情況下，系統(tǒng)處理能力隨用戶數(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ù)各操作響應時間對比圖：平均響應時間分析：同樣壓力的情況下，在無基礎數(shù)據(jù)的情況下，響應時間均小于5秒。當基礎數(shù)據(jù)量在1800萬的時候，6000用戶壓力下響應時間大幅度提高，超過客戶所提出5秒之內的要求。 5.2.2 處理

15、能力對比下圖是相同壓力情況下，有基礎數(shù)據(jù)與無基礎數(shù)據(jù)系統(tǒng)的處理能力對比。處理能力分析：在有基礎數(shù)據(jù)的情況下，單從處理能力看，依然可以滿足客戶所提出的要求，但與之前的無基礎數(shù)據(jù)的處理能力比較發(fā)現(xiàn)，基礎數(shù)據(jù)的存在是對處理能力有較大影響。 5.2.3 資源利用率對比圖下圖是相同壓力情況下，有基礎數(shù)據(jù)與無基礎數(shù)據(jù)各事務資源利用率對比圖：cpu利用率分析：相同壓力下，因有基礎數(shù)據(jù)情況下響應時間變長，系統(tǒng)處理能力下降，cpu利用率也隨之下降，這說明系統(tǒng)瓶頸出現(xiàn)在了其他方面。5.3 系統(tǒng)穩(wěn)定性測試在系統(tǒng)測試過程中，我們發(fā)現(xiàn)weblogic的jvm可用內存逐漸減少， 下圖是在weblogic監(jiān)控臺所監(jiān)控到的情

16、況：為了驗證確認此現(xiàn)象，進行了4500用戶6個小時的測試，當測試執(zhí)行到1小時左右，weblogic jvm基本已無內存可用，如下圖所示：被占用內存無法釋放，導致被測系統(tǒng)在長時間運行后響應時間明顯上升，處理能力明顯下降，如下圖所示：分析： 用戶在登錄時，系統(tǒng)會自動生成一個session，并占用部分內存，而這個session的過期時間設置為2小時，按照用戶習慣分析，當用戶使用直接關閉ie窗口退出系統(tǒng)的方式退出，這個session是不釋放的，并繼續(xù)占用內存。測試過程中沒有做退出操作，導致大量用戶session不釋放。根據(jù)上圖顯示，40分鐘時性能開始下降，此時在線用戶數(shù)約為37.5*60*40=900

17、00。解決方法：開發(fā)人員修改程序，點擊重新登錄時清除session，并在測試過程中，完成開具發(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.96 無合同_登錄6.27 無合同_開具發(fā)票

18、4.45 無合同_錄入并開具6.18 無合同_退出3.84 說明：此時有合同的開具發(fā)票、選擇合同操作的響應時間已遠遠超過5秒，其它大部分操作響應時間也超過了5秒。5.4.2 處理能力對比圖下圖是無合同4500用戶與有合同4500用戶情況下系統(tǒng)處理能力對比圖：分析：此時系統(tǒng)處理能力仍然滿足4小時20萬張發(fā)票的要求，但因響應時間過長，認為系統(tǒng)性能不滿足要求。5.4.3 資源利用率對比圖資源利用率分析：因響應時間過長，出現(xiàn)大量的隊列等待，導致cpu利用率下降。5.5 業(yè)務場景二調優(yōu)對比測試現(xiàn)象：有合同“開具發(fā)票”、“選擇合同”操作的響應時間過長。通過數(shù)據(jù)庫監(jiān)控可以看到，數(shù)據(jù)庫的讀操作過于頻繁，db

19、file sequential read等待事件占總等待時間的92%以上。分析：經(jīng)過對系統(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=正常select iv_amount from hi_invoice where bg_code=:1 and (iv_s

20、tate=正常 or iv_state=沖紅) and iv_state_2=正常經(jīng)開發(fā)人員確認，這兩個sql是查詢合同信息使用的sql。2、 系統(tǒng)參數(shù)a) weblogic線程數(shù)設置過?。籦) oracle的shared pool、buffer cache設置過小。我們對各原因分別進行優(yōu)化后進行測試，最終進行了以下調整：1、 調整shard pool為104mb2、 調整buffer cache為504mb3、 調整查詢合同信息業(yè)務邏輯4、 修改weblogic線程數(shù)為150調優(yōu)結果見以下分析。5.5.1 第一次調優(yōu)首先修改業(yè)務邏輯，在進入開具發(fā)票頁面時不加載合同信息。然后修改數(shù)據(jù)庫參數(shù)，修

21、改shard pool為104m、修改buffer cache為504m。下圖是4500用戶調優(yōu)前后響應時間對比圖：事務名稱平均響應時間（調優(yōu)前）平均響應時間（調優(yōu)后）合同_登錄6.07 1.2合同_開具發(fā)票37.83 1.283合同_錄入并開具6.38 1.378合同_退出3.85 0.232合同_選擇合同34.96 0.483開票_登錄6.27 1.215開票_開具發(fā)票4.45 0.568開票_錄入并開具6.18 1.492開票_退出3.84 0.269在圖中我們可以看出調優(yōu)前后，在相同壓力的情況下，響應時間大幅度下降。調優(yōu)效果明顯，已滿足響應時間小于5秒的業(yè)務要求。此時系統(tǒng)處理能力也有明

22、顯的提升。5.5.2 第二次調優(yōu)由于此時weblogic線程經(jīng)常出現(xiàn)隊列，因此將weblogic線程最大值由100調整為150。調整后系統(tǒng)處理能力由36.004上升為37.394。但由于此時系統(tǒng)處理能力已接近場景設計最大值，因此效果不明顯，需要進行一次6000用戶的對比測試。6000用戶時，響應時間明顯變長，部分操作已超過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用戶的對比測試，結果如下：可以看出，調整業(yè)務邏輯后，各操作響應時間大幅度縮短，系統(tǒng)處理能力有了明顯提升。此時系統(tǒng)處理能力達到每小時164876筆。6 測試結論6.1 業(yè)務場景一（無合同）1、 系統(tǒng)在測試硬件、無基礎數(shù)據(jù)的情況下，系統(tǒng)處理能力達到每小時173880筆開發(fā)票業(yè)務，滿足客戶所提出的4小時處理20萬筆開發(fā)票業(yè)務，響應時間小于5秒的處理能力。2、 系統(tǒng)在測試硬件、有基礎數(shù)據(jù)（1800萬條）的情況下，系統(tǒng)處理能力達到每小時122580筆開發(fā)票業(yè)務，滿足客戶