【正文】 1 概述 測試目的本次測試的主要目的如下：? 定位電銷系統(tǒng)清分功能在交易量較大的情況下 QueueData 隊(duì)列堵塞問題；? 獲取電銷系統(tǒng)清分功能的容量，評估是否滿足未來 1 年的業(yè)務(wù)需求；? 通過性能測試，估算出應(yīng)用系統(tǒng)最優(yōu)的參數(shù)配置； 測試背景針對 PICC 電銷系統(tǒng)在生產(chǎn)交易量過大情況下，清分功能出現(xiàn)了 QueueData 隊(duì)列堵塞情況對正常業(yè)務(wù)產(chǎn)生了影響。由于電銷系統(tǒng)業(yè)務(wù)發(fā)展迅速，針對系統(tǒng)未來 1 年的業(yè)務(wù)增長情況進(jìn)行性能及風(fēng)險(xiǎn)評估。? JVM Heap：指 Java 虛擬機(jī)的內(nèi)存占用大小。用于觀察那個(gè)時(shí)間點(diǎn)上 Java 虛擬機(jī)正在做的事情。? JMS：即 Java 消息服務(wù)（Java Message Service） ，本文中 Weblogic 中用到的消息隊(duì)列，可以通過觀察消息隊(duì)列中消息的處理情況，來判斷測試性能測試的執(zhí)行情況。? PNOqueue ：投保單生成之后會(huì)在 PNOqueue 中生成相應(yīng)的消息數(shù)據(jù)。PICC 電銷系統(tǒng)清分功能性能測試報(bào)告 2 ? queueR 和 queueData 都是用來存放分中心返回給總中心的消息數(shù)據(jù)。? MessageCurrentCount：指當(dāng)前消息隊(duì)列中所存在的消息數(shù)量。CPU 的整體使用率包括 User%和 Sys%。? TF 流程：指見費(fèi)上收流程。 測試地點(diǎn)北京市朝陽區(qū)中國人民財(cái)產(chǎn)保險(xiǎn)股份有限公司電銷中心。測試方法:? 針對系統(tǒng)投保單下發(fā)交易，向電銷系統(tǒng)發(fā)起業(yè)務(wù)壓力請求；? 按照并發(fā)梯度增加的方法，逐步提升對電銷系統(tǒng)的壓力，每組梯度運(yùn)行 10 分鐘；? 觀察應(yīng)用服務(wù)器與數(shù)據(jù)庫服務(wù)器 CPU、內(nèi)存、磁盤的占用情況和交易響應(yīng)情況；? 觀察數(shù)據(jù)庫在不同壓力下的性能表現(xiàn)；PICC 電銷系統(tǒng)清分功能性能測試報(bào)告 3 見費(fèi)上收測試測試目的：驗(yàn)證電銷系統(tǒng)見費(fèi)上收性能情況。無法同是監(jiān)控三個(gè)隊(duì)列的運(yùn)行狀態(tài)，考慮到 PI 流程與 TI（投保單號下發(fā)）流程流程的相似性，故 TF 測試時(shí)，僅監(jiān)控了PNOqueue 和 queueData 兩個(gè)隊(duì)列的處理情況。見費(fèi)上收交易（TF）：提前預(yù)埋見費(fèi)上收數(shù)據(jù)，通過改變見費(fèi)上收輪訓(xùn)機(jī)制的觸發(fā)方法，向電銷系統(tǒng)發(fā)起投保單交易壓力，并分別進(jìn)行不同數(shù)據(jù)量的梯度測試，獲取不同壓力情況下隊(duì)列、數(shù)據(jù)庫使用情況。 測試指標(biāo)描述性能監(jiān)控指標(biāo) ? 隊(duì)列使用情況；? 交易執(zhí)行效率，即 TPS? Java 虛擬機(jī)資源消耗情況PICC 電銷系統(tǒng)清分功能性能測試報(bào)告 4 主機(jī)資源指標(biāo)? 觀察所有應(yīng)用主機(jī) CPU、內(nèi)存、I/O 等資源消耗，在梯度壓力測試中是否達(dá)到臨界值。3 測試環(huán)境 網(wǎng)絡(luò)部署圖總 中 心數(shù) 據(jù) 庫 服 務(wù) 器總 中 心應(yīng) 用 服 務(wù) 器分 中 心應(yīng) 用 服 務(wù) 器分 中 心數(shù) 據(jù) 庫 服 務(wù) 器 業(yè)務(wù)流程圖電銷投保流程示意圖，紅色框中為清分模塊。PICC 電銷系統(tǒng)清分功能性能測試報(bào)告 6 測試服務(wù)器配置序號 服務(wù)器 數(shù)量 硬件配置 操作系統(tǒng) 軟件版本1 數(shù)據(jù)庫 1 32CPU 32G 內(nèi)存 Solaris 10 Oracle 2 中間件 1 2CPU 24G 內(nèi)存 Solaris 10 Weblogic Comment [p1]: 此輪測試為測試摸索階段，發(fā)現(xiàn)了嚴(yán)重的消息丟失功能問題。PICC電銷系統(tǒng)清分功能性能測試報(bào)告 7 4 測試結(jié)果 測試流程及說明第一輪測試，主要進(jìn)行了 TI流程的 5000、10000 和 15000三個(gè)數(shù)據(jù)量級別的性能測試。? 測試環(huán)境中數(shù)據(jù)庫連接數(shù)經(jīng)常出現(xiàn)滿的情況，導(dǎo)致測試進(jìn)行時(shí)無法連接數(shù)據(jù)庫。? 在高數(shù)據(jù)量并發(fā)下，由于清分系統(tǒng)的生成流水號規(guī)則只精確到毫秒級別，導(dǎo)致測試過程中出現(xiàn)不同的記錄使用同樣的流水號，在數(shù)據(jù)量中報(bào)唯一性主鍵約束。此問題是較嚴(yán)重的功能性缺陷，經(jīng)與客戶與項(xiàng)目組協(xié)商決定，需先停止本輪性能測試，修正系統(tǒng)缺陷后，再重新執(zhí)行測試。圖 411 5000數(shù)據(jù)量 TI流程 PNOqueueTPSPICC 電銷系統(tǒng)清分功能性能測試報(bào)告 8 圖 412 10000 數(shù)據(jù)量 TI 流程 PNOqueueTPS圖 413 15000 數(shù)據(jù)量 TI 流程 PNOqueueTPS上面三個(gè)圖，分別描述從 PNOqueue 中取消息時(shí)，系統(tǒng)的 TPS 值，可以發(fā)現(xiàn)，在數(shù)據(jù)量為 5000 時(shí)，TPS 值為 116 左右。數(shù)據(jù)量從 5000 增加到 10000 出現(xiàn)很大的 TPS 差異，是由于在測試 5000 數(shù)據(jù)量時(shí)，有某幾個(gè)分中心數(shù)據(jù)庫未成功連接。大量消息在數(shù)據(jù)庫中的狀態(tài)為“發(fā)送中” 。下表描述了三個(gè)數(shù)據(jù)量下的系統(tǒng)運(yùn)行的 TPS 和執(zhí)行時(shí)間的對比。本輪測試需重新執(zhí)行前面已經(jīng)執(zhí)行過的 TI 流程測試。參數(shù)值從 1 開始，以 5 個(gè)單位遞增。? 20220 數(shù)據(jù)量 TI 測試：在此數(shù)據(jù)量下，驗(yàn)證 TI 流程的性能表現(xiàn)，主要監(jiān)控PNOqueue 和 queueR 兩個(gè)隊(duì)列。? 20220 數(shù)據(jù)量 TF 測試：在此數(shù)據(jù)量下，驗(yàn)證 TF 流程的性能表現(xiàn)，主要監(jiān)控queueData 隊(duì)列。 測試結(jié)果本節(jié)測試結(jié)果主要描述第二輪性能測試的測試結(jié)果，包括投保單下發(fā)測試和見費(fèi)上收測試兩個(gè)部分。其中 5000 數(shù)據(jù)量主要驗(yàn)證應(yīng)用配置參數(shù)的變更對系統(tǒng)性能的影響。下面詳細(xì)描述這五個(gè)階段系統(tǒng)性能表現(xiàn)。圖 42圖 42圖 423 分別描述了線程數(shù)為 1 時(shí) JVM Heap、TPS、JMS 處理三個(gè)性能指標(biāo)的情況。下圖為性能測試過程中，監(jiān)控的系統(tǒng) CPU 使用情況。 （注：1. 本文 CPU 使用率是指整個(gè)測試環(huán)境范圍內(nèi)，而非僅指清分系統(tǒng)；2. 本文中 CPU 使用率為應(yīng)用程序所在服務(wù)器的 CPU 使用情況，而非數(shù)據(jù)庫服務(wù)器）PICC 電銷系統(tǒng)清分功能性能測試報(bào)告 11 圖 424 5000 數(shù)據(jù)量 TI 流程系統(tǒng) CUP 使用處理情況（1 線程）（2） 下面三個(gè)圖描述的為在線程數(shù)為 5 時(shí)，系統(tǒng)的性能表現(xiàn)。相比線程數(shù)為 1 時(shí) TPS 有了很大的提高并且取消息的時(shí)間縮短了。圖 428 5000 數(shù)據(jù)量 TI 流程系統(tǒng) CUP 使用處理情況（5 線程）（3）接下來描述線程數(shù)為 10 時(shí)系統(tǒng)的性能表現(xiàn)，觀察圖 42圖 4210 和圖 4211可以發(fā)現(xiàn)，PNOqueue 的 TPS 值為 30~33，處理時(shí)間為 2 分鐘 50。圖 429 5000 數(shù)據(jù)量 TI 流程 JVM Heap（10 線程）PICC 電銷系統(tǒng)清分功能性能測試報(bào)告 13 圖 4210 5000 數(shù)據(jù)量 TI 流程 PNOqueueTPS（10 線程）圖 4211 5000 數(shù)據(jù)量 TI 流程 JMS 處理情況（10 線程）圖 4212 5000 數(shù)據(jù)量 TI 流程系統(tǒng) CUP 使用處理情況（10 線程）（4）當(dāng)線程數(shù)增加的到 15 時(shí)，發(fā)現(xiàn)系統(tǒng)的 CPU 使用率已經(jīng)增加到 90%，同時(shí)還存在使用率達(dá)到 100%的情況（圖 4216） 。相比線程數(shù)為 10 時(shí)，TPS 提升但是時(shí)間消耗略有增加?？梢园l(fā)現(xiàn)，線程數(shù)增加到 20 相對線程數(shù)為 15 時(shí)，TPS 值并沒有提高，反而 CPU 的使用率在開始時(shí)持續(xù)為 100%。下面通過 PNOqueue 的 TPS 和系統(tǒng) CPU 空閑率來進(jìn)行參數(shù)配置情況的小結(jié)。? 在目前的測試環(huán)境下，線程數(shù)增加到 15 時(shí)，清分系統(tǒng)的工作效率最優(yōu)。? 在目前的測試環(huán)境下，線程數(shù)增加超過 15 時(shí)，不但無法提高系統(tǒng)的工作效率，還會(huì)占用很高的 CPU 利用率，甚至從某種程度上降低工作效率。本流程主要設(shè)計(jì)的隊(duì)列為 PNOqueue和 queueR。圖 4222 15000 數(shù)據(jù)量 TI 流程 JVM HeapPICC 電銷系統(tǒng)清分功能性能測試報(bào)告 18 圖 4223 15000 數(shù)據(jù)量 TI 流程 PNOqueueTPS圖 4224 15000 數(shù)據(jù)量 TI 流程 JMS 處理情況（pnoqueue ）從圖 4223 和圖 4224 中可以發(fā)現(xiàn)，從 PNOqueue 中取走 15000 條消息，時(shí)間花費(fèi)大約為 17 分鐘，PNOqueue 的 TPS 值最高超過 25 最低為 10，平均值為 16。下