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

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

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

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

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

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

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

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

9、數據庫Oracle 9i3.2測試系統3.2.1測試環境搭建測試機配置：類型數量（臺）IP配置備注控制臺1192.168.3.129Intel E4600 2.4GHzWin2003 Server內存2G/硬盤400G 7200轉負載發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是一種預測系統行為和性能的工業標準級負載測

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

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

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

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

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

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

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

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

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

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

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

21、：有合同“開具發票”、“選擇合同”操作的響應時間過長。通過數據庫監控可以看到，數據庫的讀操作過于頻繁，db file sequential read等待事件占總等待時間的 92%以上。分析：經過對系統的監控，分析得出幾點對系統性能可能造成影響的原因：1、業務邏輯a）在進入開具發票頁面時，系統就加載了全部合同信息，導致“開具發票”操作響應 時間過長；b）查詢合同信息業務邏輯有問題，導致“選擇合同”操作響應時間過長；從數據庫監控中看到，以下兩個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='正常經開發人員確認，這兩個SQL是查詢合同信息使用的 SQL2、系統參數a）WebLogic線程數設置過??；b）Oracle 的 shared pool、buffer cache設置過小。我們對各原因分別進行優化后進行測試，最終進行了以下調整：1、調整 shard pool 為 104MB2、調整 buffer cache 為 504MB3、調整查詢合

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

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

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