LoadRunner性能測試報告

1、xxx系統(tǒng)性能測試報告姓名：班級：學(xué)號：目 錄1 前言32 被測系統(tǒng)定義32.1 功能簡介32.2 性能測試指標(biāo)43 系統(tǒng)結(jié)構(gòu)及流程43.1 系統(tǒng)總體結(jié)構(gòu)43.2 功能模塊43.3 業(yè)務(wù)流程53.4 關(guān)鍵點描述63.5 性能測試環(huán)境64 性能測試64.1 性能測試概述74.2 測試目的74.3 測試方法及測試用例74.4 測試指標(biāo)及期望84.5 測試數(shù)據(jù)準(zhǔn)備104.6 運行狀況記錄105 測試過程及結(jié)果描述105.1 測試描述115.2 測試場景115.3 測試結(jié)果116測試分析和結(jié)論161 前言目前，隨著web tours訂票系統(tǒng)在生產(chǎn)狀態(tài)下日趨穩(wěn)定、成熟，系統(tǒng)的性能問題也逐步成為了我們關(guān)注

2、的焦點：隨著訂票過程中大數(shù)據(jù)量的“沖擊”，在客戶信息信息進(jìn)入時，系統(tǒng)能穩(wěn)定在什么樣的性能水平，面臨公司業(yè)務(wù)沖刺時，系統(tǒng)能否經(jīng)受住“考驗”，這些問題需要通過一個完整的性能測試來給出答案。本報告前部分即是基于上述考慮，參考科學(xué)的性能測試方法而撰寫的，用以指導(dǎo)即將進(jìn)行的web tours訂票系統(tǒng)的性能測試。2 hp web tours 系統(tǒng)定義hp web tours 訂票系統(tǒng)作為本次測試的被測系統(tǒng)，該業(yè)務(wù)系統(tǒng)的主要功能包括：搜索航班，預(yù)訂機票并查看航班路線。在本次測試中，將針對上述的功能進(jìn)行壓力測試，檢查并評估在模擬環(huán)境中，系統(tǒng)對負(fù)載的承受能力，在不同的用戶連接情況下，系統(tǒng)地吞吐能力和響應(yīng)能力，以

3、及在預(yù)計的數(shù)據(jù)容量中，系統(tǒng)能夠容忍的最大用戶數(shù)。2.1 功能簡介hp web tours 主要功能如下： 用戶注冊 登錄 查詢航班2.2 性能測試指標(biāo)本次測試是針對hp web tours 訂票系統(tǒng)的性能特征和系統(tǒng)的性能調(diào)優(yōu)而進(jìn)行的，主要需要獲得如下的測試指標(biāo)。1、系統(tǒng)的響應(yīng)能力：即在各種負(fù)載壓力情況下，系統(tǒng)的響應(yīng)時間，也就是從客戶端交易發(fā)起，到服務(wù)器端交易應(yīng)答返回所需要的時間，包括網(wǎng)絡(luò)傳輸時間和服務(wù)器處理時間。2、應(yīng)用系統(tǒng)的吞吐率：即應(yīng)用系統(tǒng)在單位時間內(nèi)完成的交易量，也就是在單位時間內(nèi)，應(yīng)用系統(tǒng)針對不同的負(fù)載壓力，所能完成的交易數(shù)量。3、應(yīng)用系統(tǒng)的負(fù)載能力：即系統(tǒng)所能容忍的最大用戶數(shù)量，也就

4、是在正常的響應(yīng)時間中，系統(tǒng)能夠支持的最多的客戶端的數(shù)量。3 系統(tǒng)結(jié)構(gòu)及流程hp web tours 訂票系統(tǒng)在實際生產(chǎn)中的體系結(jié)構(gòu)跟本次性能測試所采用的體系結(jié)構(gòu)是一樣的，交易流程也完全一致的。不過，由于硬件條件的限制，本次性能測試的硬件平臺跟實際生產(chǎn)環(huán)境略有不同。3.1 系統(tǒng)總體結(jié)構(gòu)hp web tours 訂票系統(tǒng)系統(tǒng)由用戶注冊、登錄、查詢航班等這些功能構(gòu)成。 3.2 功能模塊本次性能測試中各類交易都是由若干功能模塊組成的，每個交易都根據(jù)其執(zhí)行特點分成了若干操作步驟，每個步驟就是一個功能點（即功能模塊），在hp web tours 訂票系統(tǒng)中，各種交易及其包含的功能模塊關(guān)系如下：1 注冊2

5、登錄3 查詢航班本次壓力測試主要設(shè)計的功能模塊以及所屬的路徑如下表名稱所屬交易路徑3.3 業(yè)務(wù)流程本次性能測試中，選擇的各類交易的業(yè)務(wù)流程如下：4 注冊5 登錄6 查詢航班查詢交易的業(yè)務(wù)流程只是單一步驟的，即：輸入查詢條件后獲取查詢結(jié)果，因此在本次性能測試中只作為一個事務(wù)處理，交易流程圖略。3.4 關(guān)鍵點描述本次性能測試的關(guān)鍵點，就是查看hp web tours 訂票系統(tǒng)在并發(fā)壓力下的表現(xiàn)，即：支持的并發(fā)用戶數(shù)目和并發(fā)用戶發(fā)送頻率，以及在較大壓力下，系統(tǒng)的交易處理能力，并找出各類交易的性能瓶頸。3.5 性能測試環(huán)境本次性能測試環(huán)境與真實運行環(huán)境基本一致，都運行在同樣的硬件和網(wǎng)絡(luò)環(huán)境中，數(shù)據(jù)庫是

6、真實環(huán)境數(shù)據(jù)庫的一個復(fù)制（或縮?。鞠到y(tǒng)采用標(biāo)準(zhǔn)的cs結(jié)構(gòu)，客戶端都是通過瀏覽器訪問應(yīng)用系統(tǒng)。 其中具體的硬件和網(wǎng)絡(luò)環(huán)境如下： 服務(wù)器設(shè)備：ibm 570（dbserver）， ibm 690（apserver） 操作系統(tǒng)： windows 2003 網(wǎng)絡(luò)環(huán)境： lan（10m） 數(shù)據(jù)庫：mysql 客戶端： pc （windows ）網(wǎng)絡(luò)拓?fù)浜徒Y(jié)構(gòu)圖如下：4 性能測試從廣泛意義上講性能測試包括：壓力測試、穩(wěn)定性測試、負(fù)載能力測試和可擴(kuò)展性測試等。在不同應(yīng)用系統(tǒng)的性能測試中，需要根據(jù)應(yīng)用系統(tǒng)的特點和測試目的的不同來選擇具體的測試方案，本次hp web tours 訂票系統(tǒng)的性能測試主要是采用

7、通常的壓力測試模式來執(zhí)行的，即：逐步增加壓力，查看應(yīng)用系統(tǒng)在各種壓力狀況小的性能表現(xiàn)。在性能測試中，壓力測試主要是為了獲取系統(tǒng)在較大壓力狀況下的性能表現(xiàn)而設(shè)計并實現(xiàn)的，壓力測試主要是獲取系統(tǒng)的性能瓶頸和系統(tǒng)的最大吞吐率。4.1 性能測試概述本次壓力測試是指針對現(xiàn)行的hp web tours 訂票業(yè)務(wù)系統(tǒng)的聯(lián)機交易處理能力的測試，檢驗系統(tǒng)的吞吐率。本系統(tǒng)的壓力測試主要是針對hp web tours 訂票系統(tǒng)，檢查在日間交易高峰時期，并發(fā)用戶數(shù)較多的時候的處理能力等等。4.2 測試目的壓力測試的目的就是檢驗系統(tǒng)的最大吞吐量，檢驗現(xiàn)行的hp web tours 訂票系統(tǒng)在各種壓力交易量下的運行狀況，

8、檢驗系統(tǒng)地運行瓶頸，獲取系統(tǒng)的處理能力等等。本次針對hp web tours 訂票業(yè)務(wù)系統(tǒng)所進(jìn)行的壓力測試的測試目的為： 給出hp web tours 訂票系統(tǒng)當(dāng)前的性能狀況 定位新業(yè)務(wù)系統(tǒng)性能瓶頸或潛在性能瓶頸 總結(jié)一套合理的、可操作的、適合公司現(xiàn)實情況的性能測試方案，為后續(xù)的性能測試工作提供基本思路。4.3 測試方法及測試用例使用性能測試軟件loadrunner，對現(xiàn)行的hp web tours 訂票系統(tǒng)進(jìn)行腳本錄制、測試回放、逐步加壓和跟蹤記錄。測試過程中，由loadrunner的管理平臺調(diào)用各臺測試前臺，發(fā)起各種組合的交易請求，并跟蹤記錄服務(wù)器端的運行情況和返回給客戶端的運行結(jié)果。本次

9、測試將依照如下場景進(jìn)行測試： 用戶數(shù)功能模塊業(yè)務(wù)操作2004007001000注冊注冊登錄登錄業(yè)務(wù)查詢航班針對每個測試案例，都將采用逐步加壓和瞬間加壓兩種客戶端連接方式進(jìn)行，查看服務(wù)器端在客戶端的連接數(shù)量變化過程中對應(yīng)的處理能力，測試運行安排如下： 每隔2秒增加1個用戶連接，最多增加到200個用戶，查看并記錄運行情況 每隔2秒增加2個用戶連接，最多增加到200個用戶，查看并記錄運行情況 一次性連接10個用戶，查看記錄運行情況 一次性連接100個用戶，查看記錄運行情況4.4 測試指標(biāo)及期望在本次性能測試中，各類測試指標(biāo)包括測試中應(yīng)該達(dá)到的某些性能指標(biāo)，這些性能指標(biāo)均是來自應(yīng)用系統(tǒng)設(shè)計開發(fā)時遵循的

10、業(yè)務(wù)需求，當(dāng)某個測試的某一類指標(biāo)已經(jīng)超出了業(yè)務(wù)需求的要求范圍，則測試已經(jīng)達(dá)到目的，即可終止壓力測試。 應(yīng)用軟件級別的測試指標(biāo)：1) 聯(lián)機交易類的執(zhí)行情況 交易的平均響應(yīng)時間（期望值：15s） 交易的最大響應(yīng)時間（期望值：95%） 不同并發(fā)用戶數(shù)的狀況下的上述記錄值2）測試結(jié)果分析情況 單筆記錄的處理時間（期望值：10個） 某個時間段內(nèi)的交易處理數(shù)量 單筆能處理的最大數(shù)據(jù)量 在每個交易處理中最大（最耗時）的模塊 在不同數(shù)量的測試數(shù)據(jù)基礎(chǔ)上的上述記錄值 網(wǎng)絡(luò)級別的測試指標(biāo)： 吞吐量：單位時間內(nèi)網(wǎng)絡(luò)傳輸數(shù)據(jù)量 沖突率：在以太網(wǎng)上監(jiān)測到的每秒沖突數(shù) 操作系統(tǒng)級別的測試指標(biāo)： 進(jìn)程/線程交換率：進(jìn)程和線

11、程之間每秒交換次數(shù) cpu利用率：即cpu占用率（） 系統(tǒng)cpu利用率：系統(tǒng)的cpu占用率（） 用戶cpu利用率：用戶模式下的cpu占用率（） 磁盤交換率：磁盤交換速率 中斷速率：cpu每秒處理的中斷數(shù) 讀入內(nèi)存頁速率：物理內(nèi)存中每秒讀入內(nèi)存頁的數(shù)目 寫出內(nèi)存頁速率：每秒從物理內(nèi)存中寫到頁文件中的內(nèi)存頁數(shù)目或者從物理內(nèi)存中刪掉的內(nèi)存頁數(shù)目 內(nèi)存頁交換速率：每秒寫入內(nèi)存頁和從物理內(nèi)存中讀出頁的個數(shù) 進(jìn)程入交換率：交換區(qū)輸入的進(jìn)程數(shù)目 進(jìn)程出交換率：交換區(qū)輸出的進(jìn)程數(shù)目 數(shù)據(jù)庫級別的測試指標(biāo)： 數(shù)據(jù)庫的并發(fā)連接數(shù)：客戶端的最大連接數(shù) 數(shù)據(jù)庫鎖資源的使用數(shù)量4.5 測試數(shù)據(jù)準(zhǔn)備前期準(zhǔn)備工作包括：（1

12、） 錄制好一段完整的腳本,包括(注冊，登錄，查詢航班)（2） 進(jìn)行相關(guān)的設(shè)置4.6 運行狀況記錄記錄可擴(kuò)展性測試中的測試結(jié)果及其系統(tǒng)的運行狀況。除了記錄測試指標(biāo)以外，應(yīng)該結(jié)合測試實時記錄系統(tǒng)各個層次的資源和參數(shù)。主要包括： 硬件環(huán)境資源 服務(wù)器操作系統(tǒng)參數(shù) 網(wǎng)絡(luò)相關(guān)參數(shù) 數(shù)據(jù)庫相關(guān)參數(shù)：具體數(shù)據(jù)庫參數(shù)有所不同，結(jié)合各個數(shù)據(jù)庫獨有的特點記錄5 測試過程及結(jié)果描述hp web tours 訂票系統(tǒng)的性能測試共計執(zhí)行了2次，兩次執(zhí)行的腳本流程作了調(diào)整，其他的環(huán)境和數(shù)據(jù)都一樣。在測試數(shù)據(jù)準(zhǔn)備完備以后，第一次測試中，操作流程為每次交易都執(zhí)行用戶登錄操作，第二次測試中，操作流程為先進(jìn)行用戶登錄，然后每次交

13、易都不再執(zhí)行用戶登錄。5.1 測試描述兩次測試都是在12月22日凌晨進(jìn)行的。第一次測試執(zhí)行了30分鐘左右，執(zhí)行腳本都是采用每次交易都執(zhí)行登錄操作，測試過程中，交易的執(zhí)行速度隨著測試的進(jìn)行，越來越慢，交易的響應(yīng)時間越來越長，交易出錯（超時）情況也越來越嚴(yán)重，交易在執(zhí)行到30分鐘左右，用戶登錄交易開始大量失敗（超時）并導(dǎo)致后續(xù)的交易都無法完成，于是終止本次測試。第二次測試執(zhí)行了50分鐘左右，在第一次測試的基礎(chǔ)上，調(diào)整交易流程，讓每次交易都只登錄一次，然后順序執(zhí)行交易邏輯。測試開始初期，交易的響應(yīng)時間隨著交易并發(fā)量的增加而快速增加，在測試執(zhí)行了10分鐘左右，所有的用戶登錄操作都基本完成，此后交易響應(yīng)

14、時間開始減少，并比較平穩(wěn)的執(zhí)行，絕大部分交易執(zhí)行比較平穩(wěn)成功率也很高，除了兩個交易：xxx(audit_transaction)和 xxx(claimregister_transaction)，這兩個交易的執(zhí)行速度特別慢，交易相應(yīng)時間一直都維持在190秒左右和160秒左右，這兩個交易超時現(xiàn)象嚴(yán)重，交易成功率很低，很多交易都因為超時而失敗。5.2 測試場景測試中，使用逐步加壓的模式，采用：每隔2秒啟動1個并發(fā)用戶（vuser）的方式，即：每隔1秒，啟動1個vuser，在7分鐘左右啟動所有的vuser（200個），執(zhí)行登錄，并根據(jù)設(shè)置的時間間隔發(fā)起交易。這次測試都部署在如下的場景中。運行的腳本部署

15、在3臺pc機，主要目的就是檢查在較大壓力的情況下，xxxxx心業(yè)務(wù)系統(tǒng)的性能表現(xiàn)。 選擇了2臺pc，每臺pc機部署了70個左右并發(fā)用戶， 選擇1臺pc，部署60個左右的并發(fā)用戶，并運行l(wèi)oadrunner的控制器（controller）5.3 測試結(jié)果兩次測試ap服務(wù)器主機上的cpu利用率如下：可以看出在兩次測試執(zhí)行中第一次（1:52 2:20）測試過程中cpu的利用率都幾乎達(dá)到了100%，第二次測試中（2:45- 4:00）cpu的利用率也達(dá)到了95%以上。兩次測試在數(shù)據(jù)庫（oracle）服務(wù)器上主機上的cpu利用率如下：可以看出兩次測試執(zhí)行中第一次（1:52 2:20）測試過程中cpu的利

16、用率很低，第二次測試中（2:45- 4:00）cpu的利用率較高也達(dá)到了75%以上，但兩次測試的cpu的io等待時間卻都比較高，io和cpu利用率對照表如下：可以看出兩次測試執(zhí)行中第一次（1:52 2:20）測試過程中cpu的io等待率較低，因為大多數(shù)的交易都是用戶登錄，都壓在ap服務(wù)器上了，第二次測試中（2:45- 4:00）cpu的io 第一次測試第一次測試使用了200個并發(fā)用戶，并發(fā)用戶的啟動信息如下：各類交易的交易相應(yīng)時間 （秒）scale交易名稱最小平均最大1autouw_transaction0.023.73387.8711confirm_transaction210.203210

17、.203210.2031ctdetail_transaction105.878151.032199.4771edornoscanappinput_transaction60.704153.425259.2341generalquery_transaction0.06713.62339.0941individualquery_transaction0.78128.04264.9841issue_transaction5.14530.660.2218.531109.639210.74611.2818.55315.47410.09319.46959.271各類交易的平均響應(yīng)時間圖：可以看出隨著測試的

18、進(jìn)行，交易相應(yīng)時間逐漸增大，最終導(dǎo)致交易超時而失敗。 第二次測試第二次測試調(diào)整了交易處理邏輯，大大減少了用戶登錄的操作數(shù)目，每個用戶只執(zhí)行一次用戶登錄，然后執(zhí)行對應(yīng)的交易處理，交易過程中不再執(zhí)行用戶登錄操作。運行的并發(fā)用戶數(shù)目如下圖：在用戶登錄過程中，交易的平均響應(yīng)時間如下圖：從圖中可以看出，隨著并發(fā)用戶數(shù)量的不斷增加，所有的交易的平均響應(yīng)時間都在加大，直到并發(fā)用戶數(shù)不再增加，這時候所有的交易相應(yīng)時間下降到一定的數(shù)值，并一直穩(wěn)定在這個數(shù)值左右。在第二次測試中，各類交易的平均響應(yīng)時間如下表：（單位：秒）colorscale交易最小平均最大1audit_transaction19.481162.12207.6271autouw_transaction0.013.00149.4941claimregister_transaction75.5