性能測試報(bào)告 V1.1

《性能測試報(bào)告 V1.1》由會(huì)員分享，可在線閱讀，更多相關(guān)《性能測試報(bào)告 V1.1（25頁珍藏版）》請(qǐng)?jiān)谘b配圖網(wǎng)上搜索。

1、 秘密 <第一階段性能測試報(bào)告> 張良友 [說明： 1. 本文件中“[]”中內(nèi)容為舉例和說明文字，請(qǐng)?jiān)谖募M制時(shí)替換或刪除； 2. 若文中某章節(jié)內(nèi)容可省略、不需要或適用，請(qǐng)保留該標(biāo)題，并根據(jù)實(shí)際在內(nèi)容部分寫明“略”、“勿需”或“不適用”等，同時(shí)適當(dāng)說明原因。 3. 請(qǐng)作者注意在文檔右上角修改該文檔的密級(jí)。]一帳通卡性能測試報(bào)告 文件修訂歷史 修訂時(shí)間 修訂概要 作者 審核 批準(zhǔn) 2009-12-10 新建 張良友

2、 模板修訂歷史 版本 生效時(shí)間 變更概要 作者 審核 批準(zhǔn) 第 3 頁 共 25 頁 秘密 目錄 1. 概述 5 1.1 背景 5 1.2 目標(biāo) 5 1.3 范圍 5 1.3.1 業(yè)務(wù)范圍 5 1.3.2

3、 系統(tǒng)范圍 5 1.4 術(shù)語和縮略語 5 2. 測試內(nèi)容及測試方法 6 2.1 測試內(nèi)容 6 2.2 測試方法 6 2.2.1 性能測試流程 6 2.2.2 性能測試模型分析 7 2.2.3 評(píng)估測試和性能管理方案的規(guī)劃實(shí)施 8 2.3 工作目標(biāo) 8 3. 測試環(huán)境 8 3.1 測試環(huán)境拓?fù)鋱D 8 3.2 測試環(huán)境配置 9 3.3 測試工具及監(jiān)控工具部署 10 4. 測試場景 10 4.1 基準(zhǔn)測試場景 11 4.2 單交易場景 11 4.3 單系統(tǒng)場景 12 4.4 疲勞測試場景 12 4.5 混合交易場景 13 5. 角色和職責(zé) 13 6. 性能測試

4、總體報(bào)告 14 6.1 單業(yè)務(wù)場景性能分析 14 6.1.1 KISS系統(tǒng)交易分析 14 6.1.2 IST交易分析 15 6.1.3 ESB交易性能分析 16 6.2 綜合業(yè)務(wù)場景性能分析 16 6.2.1 系統(tǒng)吞吐量TPS分析 17 6.2.2 交易響應(yīng)時(shí)間分析 18 6.2.3 系統(tǒng)資源分析 19 7. 問題和建議 21 7.1 問題一 21 7.2 問題二 22 7.3 問題三 22 7.4 問題四 22 7.5 問題五 23 8. 附錄 23 1. 概述 本文檔為XX銀行XX系統(tǒng)性能測試方案，其內(nèi)容用于描述本次性能測試服務(wù)的實(shí)施方案，以及測試項(xiàng)目

5、組織實(shí)施的技術(shù)規(guī)范。 本文檔中描述的內(nèi)容，旨在 ? 為XX系統(tǒng)的性能狀態(tài)進(jìn)行客觀評(píng)估，提供性能數(shù)據(jù)； ? 為性能測試工作規(guī)定有效、完整的實(shí)施方案； ? 為性能測試工作規(guī)定具體的任務(wù)、角色分工、進(jìn)度計(jì)劃上的安排； 1.1 背景 滿足集團(tuán)的“一個(gè)客戶，一個(gè)賬戶，多個(gè)產(chǎn)品，多種服務(wù)”的戰(zhàn)略,XX將以標(biāo)準(zhǔn)的金融卡為基礎(chǔ)，加載其他產(chǎn)品服務(wù), XX卡與其它非銀行產(chǎn)品的關(guān)聯(lián)，將通過現(xiàn)有集團(tuán)客戶信息管理系統(tǒng)（CIF2）關(guān)聯(lián)。 系統(tǒng)要上線前對(duì)XX系統(tǒng)做性能檢驗(yàn)和評(píng)估。 1.2 目標(biāo) 要求系統(tǒng)能支持并滿足目前AS/400主機(jī)、信用卡系統(tǒng)的最大發(fā)卡量（4500萬）及交易性能指標(biāo)，不影響系統(tǒng)整體的交易

6、性能。 電話銀行IVR及人工客服能支持最大發(fā)卡量的服務(wù)。 程序沒有大的性能漏洞； 系統(tǒng)性能能夠滿足基本上線要求 1.3 范圍 1.3.1 業(yè)務(wù)范圍 XX業(yè)務(wù) 1.3.2 系統(tǒng)范圍 XX銀行業(yè)務(wù)處理系統(tǒng) XX接入平臺(tái)系統(tǒng) XX業(yè)務(wù)受理系統(tǒng) 1.4 術(shù)語和縮略語 術(shù)語/縮略詞 說明 響應(yīng)時(shí)間 TPS IST 2. 測試內(nèi)容及測試方法 此次壓力測試實(shí)施是對(duì)XXXX 系統(tǒng)性能進(jìn)行測試評(píng)估的過程，我們將依據(jù)系統(tǒng)（生產(chǎn)環(huán)境）的實(shí)際運(yùn)行現(xiàn)狀，抽取對(duì)系統(tǒng)性能產(chǎn)生較大影響的業(yè)務(wù)交易，模擬最終用戶的操作行為，構(gòu)建一個(gè)與生產(chǎn)實(shí)際相近的壓力仿真

7、模型（場景），對(duì)系統(tǒng)實(shí)施壓力測試，以此評(píng)判系統(tǒng)的整體性能的實(shí)際性能表現(xiàn)。 2.1 測試內(nèi)容 根據(jù)與相關(guān)人員的溝通和交流，此期工程上線的目標(biāo)和期限，通過對(duì)現(xiàn)有系統(tǒng)運(yùn)行數(shù)據(jù)的統(tǒng)計(jì)，結(jié)合系統(tǒng)的設(shè)計(jì)目標(biāo)和業(yè)務(wù)特點(diǎn)，遵循著發(fā)生頻率高、對(duì)系統(tǒng)或數(shù)據(jù)庫性能影響大、關(guān)鍵和核心業(yè)務(wù)等原則，本期測試內(nèi)容重點(diǎn)為銀聯(lián)交易操作及ESB驗(yàn)密功能，以及后臺(tái)批處理業(yè)務(wù)。 2.2 測試方法 此次壓力測試通過構(gòu)建與真實(shí)環(huán)境相同數(shù)據(jù)規(guī)模的壓力測試環(huán)境，采用業(yè)界成熟的自動(dòng)化性能測試工具Loadrunner，通過創(chuàng)建壓力測試程序、構(gòu)建壓力測試模型，對(duì)被測試系統(tǒng)實(shí)施自動(dòng)化壓力測試，最后形成壓力測試結(jié)果分析報(bào)告。 2.2.1

8、性能測試流程 通過自動(dòng)化測試工具模擬最終用戶向服務(wù)器發(fā)起業(yè)務(wù)請(qǐng)求，進(jìn)行性能測試。通過測試工具對(duì)測試過程中系統(tǒng)各點(diǎn)進(jìn)行監(jiān)控，每一次測試結(jié)束后工具自動(dòng)生成結(jié)果報(bào)告供分析使用。 2.2.2 性能測試模型分析 系統(tǒng)是否能夠穩(wěn)定運(yùn)行具有重要意義。因此，必須要采取科學(xué)的方法對(duì)XX系統(tǒng)進(jìn)行全面的性能驗(yàn)收測試。 XX系統(tǒng)的性能測試模型分析應(yīng)當(dāng)按照下面幾個(gè)步驟來實(shí)施： ? 業(yè)務(wù)模型建立 分析XX系統(tǒng)上線后所面臨的性能壓力的來源和類別，并且通過分析歷史交易數(shù)據(jù)來確定各種性能在整個(gè)系統(tǒng)壓力所占比例。例如確定前臺(tái)應(yīng)用子系統(tǒng)的業(yè)務(wù)類別和并發(fā)比例，后臺(tái)自動(dòng)批處理的數(shù)據(jù)數(shù)量和類別等。最終目的是建立一個(gè)能夠逼

9、真模擬帳戶管理系統(tǒng)實(shí)際運(yùn)行場景的業(yè)務(wù)模型。 ? 測試數(shù)據(jù)模型建立 根據(jù)業(yè)務(wù)模型準(zhǔn)備測試數(shù)據(jù)和基礎(chǔ)數(shù)據(jù)，確保系統(tǒng)數(shù)據(jù)庫中數(shù)據(jù)容量和真實(shí)性符合實(shí)際運(yùn)行情況。 ? 監(jiān)控模型建立 性能測試的目的不僅僅是獲得關(guān)鍵業(yè)務(wù)的性能指標(biāo)，同時(shí)也要通過性能測試監(jiān)控主機(jī)、數(shù)據(jù)庫、中間件的各個(gè)性能指標(biāo)，從而發(fā)現(xiàn)性能瓶頸，為進(jìn)一步的性能調(diào)優(yōu)提供準(zhǔn)確的參考數(shù)據(jù)。 ? 測試模型建立 對(duì)帳戶管理系統(tǒng)的測試，因該采取基準(zhǔn)測試、單業(yè)務(wù)負(fù)載測試、混合負(fù)載測試的順序來執(zhí)行。這樣做的好處，在單業(yè)務(wù)負(fù)載測試是就可以發(fā)現(xiàn)各個(gè)系統(tǒng)本身的性能缺陷，而混合負(fù)責(zé)測試時(shí)將重點(diǎn)檢查各個(gè)業(yè)務(wù)相互影響導(dǎo)致的性能缺陷。 ? 執(zhí)行模型建立 X

10、X系統(tǒng)的性能測試要測試人員、開發(fā)人員和運(yùn)維人員緊密配合，才能保證整個(gè)測試工作的成功。因此，只有建立一套規(guī)范的性能測試流程，明確各個(gè)角色的工作職責(zé)，才能使性能測試工作有序、高效的開展。 ? 風(fēng)險(xiǎn)模型建立 由于性能測試的特殊性，因此在整個(gè)測試過程中，會(huì)遇到很多導(dǎo)致整個(gè)性能測試失敗的風(fēng)險(xiǎn)。 2.2.3 評(píng)估測試和性能管理方案的規(guī)劃實(shí)施 q 測試用例的建立 在性能評(píng)估的規(guī)劃階段，通過把以文檔形式所指定的關(guān)鍵業(yè)務(wù)轉(zhuǎn)化為實(shí)際可實(shí)施的測試用例，同時(shí)分配所采集的業(yè)務(wù)數(shù)據(jù)。 q 測試場景的設(shè)置 把關(guān)鍵業(yè)務(wù)的分布轉(zhuǎn)化為評(píng)估測試的具體實(shí)施設(shè)置。 q 環(huán)境配置和系統(tǒng)就緒 在實(shí)施的開始之前，有必

11、要保證被測應(yīng)用系統(tǒng)是可用和經(jīng)歷了功能和穩(wěn)定性測試的，同時(shí)功能支持必須貫穿在整個(gè)可能影響測試實(shí)施的過程。 q 測試實(shí)施和性能監(jiān)控 按指定的流程事實(shí)評(píng)估測試，并根據(jù)關(guān)鍵業(yè)務(wù)對(duì)整個(gè)應(yīng)用系統(tǒng)的影響和已有的性能參照點(diǎn)，在評(píng)估測試當(dāng)時(shí)進(jìn)行實(shí)時(shí)的性能監(jiān)控。 q 實(shí)時(shí)預(yù)警和被測試系統(tǒng)的避險(xiǎn) 針對(duì)在線系統(tǒng)的特定，在對(duì)被測試系統(tǒng)實(shí)施評(píng)估時(shí)必須有嚴(yán)格的實(shí)時(shí)預(yù)警和保護(hù)的自動(dòng)控制，一旦被測試應(yīng)用有異常的趨勢和可能，必須有及時(shí)的避險(xiǎn)機(jī)制。 2.3 工作目標(biāo) ? 構(gòu)建與實(shí)際環(huán)境相匹配的基礎(chǔ)數(shù)據(jù)環(huán)境 ? 根據(jù)系統(tǒng)性能需求設(shè)計(jì)性能測試方案，定義業(yè)務(wù)模型及測試場景 ? 執(zhí)行性能測試，獲取參測系統(tǒng)的各項(xiàng)性

12、能指標(biāo) ? 對(duì)比各參測系統(tǒng)的性能指標(biāo)，制作綜合評(píng)測報(bào)告，為評(píng)測系統(tǒng)性能及性能優(yōu)化提供參考依據(jù)。 ? 檢驗(yàn)系統(tǒng)上線前，程序是否有大的并發(fā)漏洞，和性能瓶頸 3. 測試環(huán)境 3.1 測試環(huán)境拓?fù)鋱D 第一階段測試采用擋板程序，交易不發(fā)送到AS400和V+：詳細(xì)信息如下圖： 3.2 測試環(huán)境配置 本次測試環(huán)境都是單機(jī)模式，和真實(shí)環(huán)境有區(qū)別，生產(chǎn)環(huán)境是雙機(jī)； 服務(wù)器類型 IP地址 硬件 操作系統(tǒng)信息 應(yīng)用軟件信息 CPU 內(nèi)存 存儲(chǔ) 操作系統(tǒng) 版本 應(yīng)用軟件 版本 WebLogic 10.31.102.11 4 * 2 GHz 16Gb 80Gb

13、 RedHat Linux AS 4 JDK j2sdk1.4.2_ 　 weblogic8.x? 　 　 Oracle Client 10g Release 10.2.0.2 10.31.102.10 2 * 2 GHz 16Gb 80Gb RedHat Linux AS 4 JDK j2sdk1.4.2_ 　 weblogic8.x? 　 　 Oracle Client 10g Release 10.2.0.2 Web服務(wù)器 10.39.100.10 2 * 2 GHz 16Gb 80Gb RedHat Linux AS

14、4 　 　 　 　 10.39.100.11 2 * 2 GHz 16Gb 80Gb RedHat Linux AS 4 　 　 　 　 數(shù)據(jù)庫服務(wù)器 10.31.22.27/kissstg 8 * 3.5 GHz 32Gb 160Gb AIX 5.3.0 Oracle 10g Server 10.2.0.2 IST服務(wù)器 　 4 * 1.6GHz 16Gb 80Gb AIX 5.3.0 　 　 10.37.174.18 PACES-KISS1.5.2 　 　 　 　 ?? 10.37.174.19?? Or

15、acle Client 10g Release 10.2.0.2 3.3 測試工具及監(jiān)控工具部署 測試工具 采用Loadrunner8.1， 數(shù)據(jù)庫監(jiān)控采用I3，系統(tǒng)資源監(jiān)控采用OPVM。具體信息如下： 工具名稱 許可證要求 IP地址 服務(wù)器配置要求 操作系統(tǒng)要求 應(yīng)用軟件信息 CPU 內(nèi)存 存儲(chǔ) 操作系統(tǒng) 版本 應(yīng)用軟件 版本 HP LoadRunner 支持Web協(xié)議和socket協(xié)議 10.31.180.10 4 * 2 GHz 8Gb 160Gb Windows 2003 Enterprise Edition SP1 LoadRu

16、nner Controller 8.1 N/A 10.31.180.11/13 2 * 2 GHz 4Gb 80Gb Windows 2003 Enterprise Edition SP1 LoadRunner Load Generator 8.1 I3 　Oracle監(jiān)控 http://i3fp-:20720/index.html 　 OVPM 系統(tǒng)監(jiān)控 :8080/OVPM/PMLogin.jsp?authenticate=4 　 4. 測試場景 分析XX系統(tǒng)上線后所面臨的性能壓力的來源和類別，并且通過分析歷史交易數(shù)據(jù)來確定各種性能在整個(gè)系統(tǒng)

17、壓力所占比例。例如確定前臺(tái)應(yīng)用子系統(tǒng)的業(yè)務(wù)類別和并發(fā)比例，后臺(tái)自動(dòng)批處理的數(shù)據(jù)數(shù)量和類別等。最終目的是建立一個(gè)能夠逼真模擬帳戶管理系統(tǒng)實(shí)際運(yùn)行場景的業(yè)務(wù)模型。選擇如下交易類型： l ATM查詢 l ATM取現(xiàn) l CDM存現(xiàn) l POS消費(fèi) l 查詢協(xié)議 l 查詢狀態(tài) l 更新協(xié)議 l 更新狀態(tài) l 修改重置密碼 u 驗(yàn)證密碼 4.1 基準(zhǔn)測試場景 基準(zhǔn)測試場景用來驗(yàn)證系統(tǒng)功能完整性和可用性，以及測試腳本的可重復(fù)性： 序號(hào) 功能名稱 功能點(diǎn) 并發(fā) 循環(huán)次數(shù) 操作間隔 循環(huán)間隔 (ThinkTime) 1 IST ATM查詢 1 5 5 0

18、 2 ATM取現(xiàn) 1 5 5 0 3 CDM存現(xiàn) 1 5 5 0 4 POS消費(fèi) 1 5 5 0 5 ESB 修改重置密碼 1 5 5 0 6 驗(yàn)證密碼 1 5 5 0 7 KISS 查詢協(xié)議 1 5 5 0 8 查詢狀態(tài) 1 5 5 0 9 更新協(xié)議 1 5 5 0 合計(jì) 更新狀態(tài) 1 5 5 0 　 　 　 4.2 單交易場景 單交易測試場景主要是為了檢驗(yàn)各功能模塊是否有嚴(yán)重的性能障礙，以及檢驗(yàn)各自交易單獨(dú)的性能處理能力的最大值： 序號(hào) 功能名稱 場景子序號(hào)

19、 并發(fā)人數(shù) 循環(huán)時(shí)間 1 ATM查詢 1 30 50 100 200 15分鐘 2 ATM取現(xiàn) 2 30 50 100 200 15分鐘 3 CDM存現(xiàn) 3 30 50 100 200 15分鐘 4 POS消費(fèi) 4 30 50 100 200 15分鐘 5 查詢協(xié)議 5 30 50 100 200 15分鐘 6 查詢狀態(tài) 6 30 50 100 200 15分鐘 7 更新協(xié)議 7 30 50 100 200 15分鐘 8 跟新狀態(tài) 8 30 50 100 200

20、15分鐘 9 修改重置密碼 9 30 50 100 200 15分鐘 10 驗(yàn)證密碼 10 30 50 100 200 15分鐘 11 　 … 　 　 　 　 … 　 　 　 　 　 　 　 　 合計(jì) 　 　 　 　 　 用戶調(diào)度方式: 采用每秒鐘增加5個(gè)用戶，場景結(jié)束時(shí)每秒鐘退出5個(gè)用戶。每筆交易間隔時(shí)間5秒，即設(shè)置think time時(shí)間； 4.3 單系統(tǒng)場景 分別執(zhí)行經(jīng)過Proxy程序?qū)ST測測試，通過ESB的測試場景和KISS應(yīng)用的測試場景： 序號(hào) 功能名稱 功能點(diǎn) 并發(fā) 操作間隔 循

21、環(huán)間隔 (ThinkTime) 1 IST ATM查詢 10 25 50 5 0 ATM取現(xiàn) 10 25 50 5 0 CDM存現(xiàn) 10 25 50 5 0 POS消費(fèi) 10 25 50 5 0 2 ESB 修改重置密碼 25 50 100 5 0 驗(yàn)證密碼 25 50 100 5 0 3 KISS 查詢協(xié)議 10 25 50 5 0 合計(jì) 查詢狀態(tài) 10 25 50 5 0 更新協(xié)議 10 25 50 5 0 更新狀態(tài) 10 25 50 5 0 　 　

22、 　 　 　 4.4 疲勞測試場景 采用100用戶并發(fā)，持續(xù)執(zhí)行8小時(shí)。 序號(hào) 功能名稱 功能點(diǎn) 所占比例 循環(huán)次數(shù) 操作間隔 執(zhí)行時(shí)間 (ThinkTime) 1 IST ATM查詢 15% 1 5 8小時(shí) 2 ATM取現(xiàn) 10% 1 5 8小時(shí) 3 CDM存現(xiàn) 8% 1 5 8小時(shí) 4 POS消費(fèi) 20% 1 5 8小時(shí) 5 ESB 查詢協(xié)議 4% 1 5 8小時(shí) 6 查詢狀態(tài) 4% 1 5 8小時(shí) 7 更新協(xié)議 2% 1 5 8小時(shí) 8 更新狀態(tài) 2% 1 5

23、8小時(shí) 9 KISS 修改重置密碼 5% 1 5 8小時(shí) 10 驗(yàn)證密碼 30% 1 5 8小時(shí) 合計(jì) 　 　 4.5 混合交易場景 按照分析的業(yè)務(wù)模型，對(duì)不同交易按照一定比例，分別執(zhí)行不同壓力的下的測試場景： 序號(hào) 功能名稱 功能點(diǎn) 所占比例 并發(fā) 操作間隔 循環(huán)間隔 50 100 150 200 (ThinkTime) 1 IST ATM查詢 15% 　 　 　 　 5 0 2 ATM取現(xiàn) 10% 　 　 　 　 5 0 3 CDM存現(xiàn) 8% 　 　 　 　 5 0 4

24、 POS消費(fèi) 20% 　 　 　 　 5 0 5 KISS 查詢協(xié)議 4% 　 　 　 　 5 0 6 查詢狀態(tài) 4% 　 　 　 　 5 0 7 更新協(xié)議 2% 　 　 　 　 5 0 8 更新狀態(tài) 2% 　 　 　 　 5 0 9 ESB 修改重置密碼 5% 　 　 　 　 5 0 10 驗(yàn)證密碼 30% 　 　 　 　 5 0 合計(jì) 　 　 　 　 　 　 5. 角色和職責(zé) 部門和角色 職責(zé) 人員 測試人員 監(jiān)督項(xiàng)目執(zhí)行過程和執(zhí)

25、行結(jié)果，推進(jìn)和執(zhí)行質(zhì)量保障體系工作流程，對(duì)項(xiàng)目中重大問題進(jìn)行決策，協(xié)調(diào)項(xiàng)目所需的軟硬件資源和人力資源。 搭建測試開發(fā)環(huán)境,測試數(shù)據(jù)準(zhǔn)備、被測系統(tǒng)（生產(chǎn)環(huán)境）的數(shù)據(jù)備份和清除、并提供技術(shù)支持和配合，解決測試過程中出現(xiàn)的各種技術(shù)問題 開發(fā)人員 同測試項(xiàng)目進(jìn)行溝通，解決應(yīng)用程序出現(xiàn)的各種問題，協(xié)調(diào)相關(guān)技術(shù)人員。 性能測試專家 需求調(diào)研分析，參與設(shè)計(jì)測試模型和方案，指導(dǎo)測試工程師開展工作； 對(duì)測試中的問題進(jìn)行分析和定位，協(xié)調(diào)組織整個(gè)性能測試過程，制定測試計(jì)劃和方案； 負(fù)責(zé)對(duì)測試案例的業(yè)務(wù)流程進(jìn)行指導(dǎo)、評(píng)審和確認(rèn)。測試范圍的指定，測試需求確認(rèn)； 性能測試工程師 進(jìn)行測試

26、準(zhǔn)備和測試執(zhí)行工作 數(shù)據(jù)庫專家 協(xié)助解決數(shù)據(jù)庫相關(guān)問題 　 6. 性能測試總體報(bào)告 XX系統(tǒng)第一階段性能測試，共執(zhí)行了85個(gè)場景，其中包括單業(yè)務(wù)場景，混合業(yè)務(wù)場景，單系統(tǒng)場景，和疲勞測試場景； IST系統(tǒng)在目前硬件環(huán)境和數(shù)據(jù)環(huán)境下，最大吞吐量TPS達(dá)到10個(gè)，最大并發(fā)用戶數(shù)達(dá)到200個(gè)，當(dāng)用戶并發(fā)100個(gè)時(shí)，系統(tǒng)交易響應(yīng)時(shí)間3秒左右。下一章會(huì)有詳細(xì)介紹； 系統(tǒng)在壓力測試過程中主要是IST系統(tǒng)CPU利用率過高，當(dāng)并發(fā)達(dá)到100時(shí)，系統(tǒng)CPU利用率就達(dá)到80%，其他指標(biāo)正常；另外數(shù)據(jù)庫服務(wù)器主要表現(xiàn)為IO過高，持續(xù)壓力半小時(shí)系統(tǒng)IO就維持在100%，導(dǎo)致不能及時(shí)響應(yīng)，出現(xiàn)交易

27、失敗， 壓力測試過程中，交易成功率一直在98%以上； 分別從單業(yè)務(wù)場景和混合業(yè)務(wù)場景對(duì)系統(tǒng)性能狀況做詳細(xì)的分析； 6.1 單業(yè)務(wù)場景性能分析 6.1.1 KISS系統(tǒng)交易分析 最大并發(fā)用戶數(shù)為100，響應(yīng)時(shí)間均在1秒以內(nèi)，查詢客戶協(xié)議交易響應(yīng)時(shí)間最長為0.187秒，TPS值在37左右，而且還有繼續(xù)提升的潛力；沒有發(fā)現(xiàn)系統(tǒng)資源異常。其中查詢卡狀態(tài)交易有少量錯(cuò)誤，錯(cuò)誤返回代碼 1001；編號(hào) 場景名稱 執(zhí)行時(shí)間 并發(fā)用戶數(shù) 平均響應(yīng)時(shí)間 平均TPS 正確率 IST系統(tǒng)資源情況 異常情況 備注 　 　 　 　 　 　 　 CPU MEM IO 　

28、　 S_001 單業(yè)務(wù)測試-查詢客戶協(xié)議 2009-11-30 100 0.187 36.8 100% 正常 正常 正常 　 　 S_002 單業(yè)務(wù)測試-更新客戶協(xié)議 2009-11-30 100 0.035 36.6 100% 正常 正常 正常 　 　 S_003 單業(yè)務(wù)測試-查詢卡狀態(tài) 2009-11-30 100 0.037 37.3 98% 正常 正常 正常 錯(cuò)誤代碼1001 　 S_004 單業(yè)務(wù)測試-更新卡協(xié)議 2009-12-1 100 0.078 37.6 100% 正常 正常 正常

29、　 　 S_005 KISS(HTTP)測試場景 2009-11-30 100 0.053 30.7 99% 正常 正常 正常 　 　 具體信息如下表： 6.1.2 IST交易分析 分別測試了25用戶、50用戶、100用戶和150用戶并發(fā)的場景，其中50個(gè)并發(fā)的時(shí)候平均響應(yīng)時(shí)間3秒，TPS是5個(gè)；IST服務(wù)器CPU利用率在60%左右；成功率都在90%左右（和擋板程序設(shè)置有關(guān)）； 在100用戶并發(fā)數(shù)據(jù)如下表內(nèi)容，CPU利用率飽和、TPS為10個(gè)左右、平均響應(yīng)時(shí)間6秒左右。此時(shí)系統(tǒng)吞吐量達(dá)到最高； 編號(hào) 場景名稱 執(zhí)行時(shí)間 并發(fā)用

30、戶數(shù) 平均響應(yīng)時(shí)間 平均TPS 正確率 IST系統(tǒng)資源情況 異常情況 備注 　 　 　 　 　 　 　 CPU MEM IO 　 　 S_006 單業(yè)務(wù)測試-ATM查詢 2009-12-4 100 6.3 10.9 85% 異常（備注） 正常 正常 CPU利用率超過90% 成功率和擋板程序設(shè)置有關(guān) S_007 單業(yè)務(wù)測試-POS消費(fèi) 2009-12-4 100 6.1 9.7 90% 異常（備注） 正常 正常 CPU利用率超過90% 　 S_008 單業(yè)務(wù)測試-ATM取現(xiàn) 2009-12-4 100

31、6.8 9.2 90% 異常（備注） 正常 正常 CPU利用率超過90% 　 S_009 IST（proxy）測試場景 2009-12-4 100 5.7 9.3 90% 異常（備注） 正常 正常 CPU利用率超過90% 　 6.1.3 ESB交易性能分析 并發(fā)用戶數(shù)分別50、100、200；其中用戶并發(fā)200個(gè)時(shí)，平均響應(yīng)時(shí)間3秒左右，TPS為11個(gè)左右，CPU利用率平均在90%以上；IST服務(wù)器達(dá)到飽和；當(dāng)并發(fā)用戶超過250時(shí)，IST出現(xiàn)擁堵（mblook –t 查看） 編號(hào) 場景名稱 執(zhí)行時(shí)間 并發(fā)用戶數(shù) 平均響應(yīng)時(shí)間 平均T

32、PS 正確率 IST系統(tǒng)資源情況 異常情況 備注 　 　 　 　 　 　 　 CPU MEM IO 　 　 S_010 單業(yè)務(wù)測試-密碼驗(yàn)證 2009-12-7 200 3.1 11.2 100% 異常（備注） 正常 正常 CPU利用率90% 　 S_011 單業(yè)務(wù)測試-重置密碼 2009-12-7 200 3.1 10.8 100% 異常（備注） 正常 正常 CPU利用率90% 　 S_012 ESB場景 2009-12-7 200 　 　 100% 異常（備注） 正常 正常 CPU利用率9

33、0% 數(shù)據(jù)庫IO超高 表：ESB交易性能數(shù)據(jù) 6.2 綜合業(yè)務(wù)場景性能分析 綜合業(yè)務(wù)場景是本次測試的所有交易，按照業(yè)務(wù)場景模型進(jìn)行一定配比組合成的測試場景，并發(fā)用戶分別為50、100、150、200；具體交易和比例如下節(jié)詳細(xì)表； 分別對(duì)系統(tǒng)吞吐、交易響應(yīng)時(shí)間和系統(tǒng)資源利用情況在不同壓力下的表現(xiàn)進(jìn)行橫向和縱向的分析； 6.2.1 系統(tǒng)吞吐量TPS分析 TPS 是系統(tǒng)每秒交易數(shù)，衡量系統(tǒng)性能的重要指標(biāo)；下表是不同壓力下系統(tǒng)TPS的表現(xiàn)； 交易名 用戶比例 0用戶 50用戶 100用

34、戶 150用戶 200用戶 ATM取現(xiàn) 10% 0 0.68 0.93 1.28 0.93 ATM查詢 15% 0 0.95 1.23 1.76 1.36 POS消費(fèi) 25% 0 1.35 1.76 2.37 2.07 修改卡狀態(tài) 4% 0 0.58 1.1 1.56 2.07 修改客戶協(xié)議 4% 0 0.59 1.1 1.57 1.94 查詢卡狀態(tài) 2% 0 0.52 1.14 1.57 1.93 查詢客戶協(xié)議 2% 0 0.66 1.19 1.54 1.94 密碼修改重置 8% 0

35、 0.3 0.54 0.62 0.63 密碼校驗(yàn) 30% 0 0.92 1.48 2.04 2.18 合計(jì)TPS 0 6.55 10.47 14.31 15.05 表：綜合場景TPS 從下圖我們可以分析出，ATM取現(xiàn)、ATM查詢和POS消費(fèi)三個(gè)交易在并發(fā)用戶達(dá)到150的時(shí)候，TPS值最高，用戶并發(fā)在200時(shí)，吞吐量反而下降，說明這三支交易性能出現(xiàn)瓶頸，主要是由于IST服務(wù)器CPU資源消耗殆盡導(dǎo)致； 密碼驗(yàn)證和密碼修改兩只交易在并發(fā)150

36、和200時(shí)變化不大，說明也基本達(dá)到飽和狀態(tài)，接近系統(tǒng)最大處理能力； 查詢卡狀態(tài)、查詢客戶協(xié)議、修改卡狀態(tài)和修改客戶協(xié)議四個(gè)交易的TPS隨著用戶數(shù)的增加一直在提高，說明這四個(gè)交易的處理能力還有很大提升空間，回顧上面單業(yè)務(wù)測試場景我們可以解釋，這四個(gè)交易的TPS可以達(dá)到30個(gè)； 圖：綜合場景TPS分析 6.2.2 交易響應(yīng)時(shí)間分析 通過系統(tǒng)不同壓力下，分析每支交易的響應(yīng)時(shí)間，下表是具體數(shù)據(jù)： 交易名 用戶比例 0用戶 50用戶 100用戶 1

37、50用戶 200用戶 ATM取現(xiàn) 10% 0 1.709 3.036 5.098 8.43 ATM查詢 15% 0 1.718 3.043 5.016 8.363 POS消費(fèi) 25% 0 1.851 3.166 5.373 8.607 修改卡狀態(tài) 4% 0 0.112 0.054 0.059 0.071 修改客戶協(xié)議 4% 0 0.089 0.051 0.047 0.064 查詢卡狀態(tài) 2% 0 0.102 0.044 0.033 0.033 查詢客戶協(xié)議 2% 0 0.066 0.039 0.0

38、34 0.041 密碼修改重置 8% 0 2.603 2.654 2.923 2.946 密碼校驗(yàn) 30% 0 2.723 2.88 2.94 2.98 表：綜合場景響應(yīng)時(shí)間數(shù)據(jù) 從下圖我們可以分析出，ATM取現(xiàn)、ATM查詢和POS消費(fèi)三個(gè)交易隨著并發(fā)壓力的增加，響應(yīng)時(shí)間也基本線性增長，其中在并發(fā)用戶在100個(gè)時(shí)，響應(yīng)時(shí)間基本在3秒左右，當(dāng)用戶達(dá)到200時(shí)，響應(yīng)時(shí)間接近9秒 ；說明這三支交易性能出現(xiàn)瓶頸，并且對(duì)IST服務(wù)器資源依賴性比較強(qiáng);

39、 密碼驗(yàn)證和密碼修改兩只交易在并發(fā)150和200時(shí)響應(yīng)時(shí)間變化不大； 查詢卡狀態(tài)、查詢客戶協(xié)議、修改卡狀態(tài)和修改客戶協(xié)議四個(gè)交易的TPS隨著用戶數(shù)的增加也沒有太大變化，說明同樣驗(yàn)證這四個(gè)交易的處理能力還有很大提升空間， 圖：綜合場景響應(yīng)時(shí)間分析 6.2.3 系統(tǒng)資源分析 u IST服務(wù)器 首先分析一下IST服務(wù)器主要資料使用情況，CPU、MEM和IO在不同壓力下的表現(xiàn)； 數(shù)據(jù)如下表： IST 服務(wù)器 　 0 50用戶 100用戶 150用戶 200用戶

40、 CPU 0 35% 68% 89% 95% MEM 0 40% 45% 50% 52% IO 0 5% 8% 10% 10% 從下圖我們可以看出，IST服務(wù)器隨著壓力的增大MEM和IO變化很小，而CPU利用率增長很快，當(dāng)并發(fā)用戶達(dá)到100時(shí)，CPU利用率就接近70%，并發(fā)達(dá)到200時(shí)，CPU就達(dá)到飽和，根據(jù)經(jīng)驗(yàn)CPU超過80%，系統(tǒng)性能就會(huì)下降。 圖：IST服務(wù)器資料 通過對(duì)IST服務(wù)器的分析，我們發(fā)現(xiàn)主

41、要瓶頸在ＣＰＵ的資源上。 u 數(shù)據(jù)庫服務(wù)器 在測試過程中通過監(jiān)控，數(shù)據(jù)庫服務(wù)器的資料利用情況如下表： 數(shù)據(jù)庫 服務(wù)器 　 0 50用戶 100用戶 150用戶 200用戶 CPU 0 3% 6% 8% 9% MEM 0 40% 44% 46% 52% IO 0 51% 78% 93% 100% 通過下圖可以看出，數(shù)據(jù)庫服務(wù)器的ＣＰＵ利用率很低，不超過１０％，內(nèi)存的情況一般也維持在５０％左右，ＩＯ的變化非常明顯，隨著壓力的增加，系統(tǒng)ＩＯ不斷增加，并且持續(xù)維持在１００％；

42、 圖：數(shù)據(jù)庫資源分析 通過對(duì)數(shù)據(jù)庫服務(wù)器的分析，主要瓶頸在系統(tǒng)ＩＯ上，在大壓力下ＩＯ利用率會(huì)持續(xù)１００％。 7. 問題和建議 在測試過程中主要發(fā)現(xiàn)以下幾個(gè)問題，并給出了初步建議。 7.1 問題一 當(dāng)并發(fā)壓力用戶100以上時(shí)IST服務(wù)器（10.37.174.18）CPU利用率就會(huì)持續(xù)很高，平均超過80%，監(jiān)控?cái)?shù)據(jù)如下圖所示： 建議：本次測試ＩＳＴ服務(wù)器ＣＰＵ為　4 * 1.6GHz，想繼續(xù)提高ＩＳＴ系統(tǒng)性能，主要方法有增加ＣＰＵ數(shù)量，提供ＣＰＵ主頻，或者系統(tǒng)集群部分；另外也可以考慮修改應(yīng)

43、用程序，提高應(yīng)用程序本身的效率；減少單位進(jìn)程的ＣＰＵ資源的消耗； 7.2 問題二 根據(jù)目前測試環(huán)境IST硬件配置情況， 啟動(dòng)ＩＳＴ進(jìn)程（ｓｈｃ）個(gè)數(shù)，也會(huì)影響到系統(tǒng)性能，下圖是測試過程中并發(fā)１００用戶，初始的ｓｈｃ進(jìn)程是２個(gè)，此時(shí)的ＴＰＳ維持在３左右；當(dāng)ｓｈｃ進(jìn)程數(shù)啟動(dòng)７個(gè)時(shí)，發(fā)現(xiàn)ｔｐｓ逐步提升，最終維持的８； 建議：測試環(huán)境級(jí)別硬件，啟動(dòng)SHC進(jìn)程在6-8個(gè)比較合理，使系統(tǒng)性能達(dá)到最大化。過少會(huì)導(dǎo)致IST擁堵，過多會(huì)消耗更多的系統(tǒng)資源，增加系統(tǒng)消耗。 7.3 問題三 ESB初始設(shè)置 tcpip.port_max 是20，當(dāng)ＥＳＢ并發(fā)請(qǐng)求超過２０個(gè)時(shí)，就會(huì)導(dǎo)致請(qǐng)求失??；

44、 建議：tcpip.port_max大于200；因?yàn)榇酥禌Q定ESB支持的最大并發(fā)連接數(shù)； 7.4 問題四 在疲勞測試場景中，發(fā)現(xiàn)測試執(zhí)行30分鐘左右出現(xiàn)ESB交易用戶fail的情況；初步判斷，由于ESB是短連接，此時(shí)數(shù)據(jù)庫系統(tǒng)IO持續(xù)100%，導(dǎo)致不能及時(shí)得到響應(yīng)（timeout 10秒），最后導(dǎo)致收不到返回報(bào)文的錯(cuò)誤； 建議：提供數(shù)據(jù)庫ＩＯ處理性能；優(yōu)化數(shù)據(jù)庫分區(qū)； 7.5 問題五 當(dāng)系統(tǒng)持續(xù)壓力的時(shí)候，出現(xiàn)數(shù)據(jù)庫IO飽和，主要原因是SHCLOG 導(dǎo)致， 建議：　將kissidx01.dbf文件分區(qū)存儲(chǔ)?；蛘咛岣呶锢泶鎯?chǔ)設(shè)備的IO效率。 8. 附錄 第 25 頁 共 25 頁 IST性能測試報(bào)告 張良友