【正文】 圖為測(cè)試過程中監(jiān)控的 CPU 利用率為 50%左右。本流程主要設(shè)計(jì)的隊(duì)列為 PNOqueue和 queueR。PICC 電銷系統(tǒng)清分功能性能測(cè)試報(bào)告 20 圖 4228 20220 數(shù)據(jù)量 TI 流程 JVM Heap圖 4229 20220 數(shù)據(jù)量 TI 流程 PNOqueueTPS圖 4230 20220 數(shù)據(jù)量 TI 流程 JMS 處理情況（pnoqueue ）從圖 4229 和圖 4230 中可以發(fā)現(xiàn)，從 PNOqueue 中取走 20220 條消息，時(shí)間花費(fèi)大約為 18 分鐘，PNOqueue 的 TPS 平均分布在 15 和 25 兩個(gè)范圍。下圖為測(cè)試過程中監(jiān)控的 CPU 利用率為 50%左右。本流程主要設(shè)計(jì)的隊(duì)列為 PNOqueue和 queueData。圖 4234 15000 數(shù)據(jù)量 TF 流程 JVM Heap圖 4235 15000 數(shù)據(jù)量 TF 流程 JMS 處理情況從圖 4235 中可以發(fā)現(xiàn)，從 queueData 隊(duì)列中取走 15000 條消息需要大約 42 分鐘，在此過程中，PNOqueue 隊(duì)列中的消息也隨著 queueData 中的消息的消費(fèi)而逐漸增多，但是消息僅返回為 10000 條。下圖為在 TF 測(cè)試過程記錄的 queueData 和 PNOqueue 的 TPS 情況，發(fā)現(xiàn) queueData 的 TPS 大約為 8~10，PNOqueue 的 TPS 為 6~15。圖 4237 15000 數(shù)據(jù)量 TF 流程系統(tǒng) CUP 使用處理情況 15000 數(shù)據(jù)量再測(cè)試由于在見費(fèi)上收測(cè)試的測(cè)試結(jié)果發(fā)現(xiàn) 20220 數(shù)據(jù)量下系統(tǒng)的性能表現(xiàn)遠(yuǎn)高于 15000 數(shù)據(jù)量，這屬于一種不合理的現(xiàn)象。為了通過性能測(cè)試，真實(shí)的表現(xiàn)應(yīng)用系統(tǒng)在 15000 數(shù)據(jù)量時(shí)在測(cè)試環(huán)境下的性能表現(xiàn)。下面幾個(gè)圖形說明了本次測(cè)試的測(cè)試結(jié)果。下圖為在 TF 測(cè)試過程記錄的 queueData 和 PNOqueue 的 TPS 情況，發(fā)現(xiàn) queueData 的 TPS 平均值在 37 左右，PNOqueue 的 TPS 大約為 15。PICC 電銷系統(tǒng)清分功能性能測(cè)試報(bào)告 25 圖 4240 15000 數(shù)據(jù)量 TF 流程 PNOqueueTPS 和 queueDataTPS下圖為 TF 測(cè)試過程中，監(jiān)控的系統(tǒng) CPU 使用率，值約為 80%?？梢园l(fā)現(xiàn)在業(yè)務(wù)空閑期，PNOqueue 的 TPS 值比較穩(wěn)定在 15 左右，queueData 的 TPS 穩(wěn)定在 37 左右，與繁忙期時(shí)相比有了很大提高。序號(hào) 業(yè)務(wù)期 需要時(shí)間1 空閑期 15 37 7 分鐘2 繁忙期 6~15 8~10 42 分鐘 20220 數(shù)據(jù)量測(cè)試本節(jié)描述在 20220 數(shù)據(jù)量下，TF 流程性能表現(xiàn)。下面將描述這兩個(gè)隊(duì)列在測(cè)試過程中的性能表現(xiàn)。下圖為在 TF 測(cè)試過程記錄的 queueData 和 PNOqueue 的 TPS 情況，發(fā)現(xiàn) queueData 的 TPS 大約為 20，PNOqueue 的 TPS 為 15。圖 4245 20220 數(shù)據(jù)量 TF 流程系統(tǒng) CUP 使用處理情況PICC 電銷系統(tǒng)清分功能性能測(cè)試報(bào)告 27 5 結(jié)果分析 線程數(shù)對(duì)系統(tǒng)性能的影響根據(jù) TI 流程 5000 數(shù)據(jù)量測(cè)試中的測(cè)試結(jié)果中，可以總結(jié)出以下幾點(diǎn)：? 增加清分系統(tǒng)的線程數(shù)，會(huì)從一定程度上提高應(yīng)用系統(tǒng)的工作效率，但是增加線程數(shù)會(huì)對(duì) CPU 產(chǎn)生更大的開銷。? 線程數(shù)設(shè)置過高，不斷不能提高應(yīng)用系統(tǒng)的工作效率，相反的還會(huì)降低系統(tǒng)的功能效率，并產(chǎn)生很高的 CPU 利用率。TPSCPU%線程數(shù)數(shù)值 Queue 隊(duì)列的處理情況根據(jù) TI 流程 20220 數(shù)據(jù)量測(cè)試和 TF 流程 20220 數(shù)據(jù)量測(cè)試兩個(gè)測(cè)試結(jié)果，來分析清分模塊中三個(gè)隊(duì)列的業(yè)務(wù)處理能力。TPS 高達(dá) 200以上。? PNOqueue 隊(duì)列的處理能力居中， TPS 值為 25 左右。找出三個(gè)隊(duì)列之間差距的原因。預(yù)估明年每日新增的投保單數(shù)據(jù)量為 2 萬筆。每日投保單數(shù)據(jù)量：20220每日工作時(shí)間：8 小時(shí)根據(jù)軟件測(cè)試中的 80/20 原則“80%的工作量，在 20%的工作時(shí)間內(nèi)完成“，可以計(jì)算完成20220 筆投保單所需要 PNOqueue 的 TPS 值：PNOqueuetps = (2022080%)∕(8360020%) ≈假定業(yè)務(wù)高峰期時(shí)的業(yè)務(wù)處理能力要求是平時(shí)的 5 倍，可以得出業(yè)務(wù)高峰期是要求的 TPS 值為：5 = 14根據(jù)計(jì)算得出完成 20220 筆投保單所需要的 PNOqueue 的 TPS 值為 14，而經(jīng)過壓測(cè)得出的 PNOqueue 的 TPS 值為 25 左右。通過監(jiān)控對(duì) queueData 的線程進(jìn)行 dump 分析，發(fā)現(xiàn) 15 個(gè)線程中有 9 個(gè)在等待或者執(zhí)行調(diào)用分公司平臺(tái)的 WebService 的結(jié)果，有 3 個(gè)在從數(shù)據(jù)庫讀取數(shù)據(jù)。從線程使用時(shí)間來分析，對(duì) WebService調(diào)用結(jié)果的等待占用了 60%以上的運(yùn)行時(shí)間。如果能夠?qū)?WebService 進(jìn)行優(yōu)化，將能夠大大縮短業(yè)務(wù)執(zhí)行時(shí)間，同時(shí)也能夠大大提高應(yīng)用程序的性能。從線程使用時(shí)間來分析，對(duì)數(shù)據(jù)庫返回結(jié)果的等待占用了 60%以上的運(yùn)行時(shí)間，如下圖所示：從上分析可以看出，數(shù)據(jù)庫查詢結(jié)果返回占用時(shí)間最長，是 pnoQueue 隊(duì)列這個(gè) JMS Client 端最大的時(shí)間消耗者。PICC 電銷系統(tǒng)清分功能性能測(cè)試報(bào)告 30 6 測(cè)試風(fēng)險(xiǎn) 測(cè)試環(huán)境相關(guān)? 測(cè)試環(huán)境與生產(chǎn)環(huán)境配置及使用狀況存在較大差異，測(cè)試結(jié)果僅能說明在目前測(cè)試環(huán)境下的性能表現(xiàn)。? 測(cè)試環(huán)境所在服務(wù)器同時(shí)運(yùn)行多個(gè)系統(tǒng)，系統(tǒng)整體負(fù)荷較高。? 數(shù)據(jù)庫服務(wù)器同時(shí)運(yùn)行多個(gè)實(shí)例，并且被測(cè)數(shù)據(jù)庫所在實(shí)例也有另外的程序在運(yùn)行，影響判斷數(shù)據(jù)庫是否存在性能瓶頸。? 無法監(jiān)控測(cè)試環(huán)境中的網(wǎng)絡(luò)資源使用情況，網(wǎng)絡(luò)環(huán)境異常也會(huì)造成測(cè)試結(jié)果不準(zhǔn)確。 測(cè)試執(zhí)行相關(guān)? 監(jiān)控隊(duì)列中消息數(shù)量情況的工具為每 5 秒收集一次，所監(jiān)控的消息消費(fèi)時(shí)間存在177。? 使用 sarmon 監(jiān)控服務(wù)器操作系統(tǒng)時(shí)，只能監(jiān)控全局的資源使用情況。? 總中心與分中心交互過程中所消耗的時(shí)間與網(wǎng)絡(luò)環(huán)境、分中心處理能力存在較大聯(lián)系，本次測(cè)試并未監(jiān)控整個(gè)業(yè)務(wù)流程所消耗的全部時(shí)間。? 由于 TF 和 PI 流程同時(shí)觸發(fā)，整個(gè)過程涉及總中心與分中心的交互，涉及總中心三個(gè)消息隊(duì)列同時(shí)運(yùn)轉(zhuǎn)。Comment [p3]: 測(cè)試環(huán)境數(shù)據(jù)庫連接數(shù)是 600。在數(shù)據(jù)庫中可以觀察到大量INACTIVE的連接仍與數(shù)據(jù)庫相連，請(qǐng)核心與核保排查此問題。Comment [p4]: 空指針異常Comment [p5]: 連接數(shù)滿導(dǎo)致數(shù)據(jù)庫連接異常PICC電銷系統(tǒng)清分功能性能測(cè)試報(bào)告 31 到 PI流程與 TI流程流程，故 TF測(cè)試時(shí)，僅監(jiān)控了 PNOqueue和queueData兩個(gè)隊(duì)列的處理情況。通過Weblogic工程師的分析初步判斷這兩個(gè)隊(duì)列慢的原因是由于調(diào)用 WebService和數(shù)據(jù)庫查詢較慢。即每日 20220筆新增投保單。 （詳情請(qǐng)看線程數(shù)對(duì)系統(tǒng)性能的影響）8 附件本次測(cè)試主要發(fā)現(xiàn)以下幾個(gè)問題：? : ORA00001: unique constraint：主鍵唯一性約束，由于清分系統(tǒng)的生成流水號(hào)規(guī)則只精確到毫秒級(jí)別，導(dǎo)致測(cè)試過程中出現(xiàn)不同的記錄使用同樣的流水號(hào)。? ? : Io 異常: Connection refusedComment [p6]: 連接數(shù)滿導(dǎo)致數(shù)據(jù)庫連接異常Comment [p7]: 請(qǐng)申國強(qiáng)確認(rèn)Comment [p8]: 請(qǐng)申國強(qiáng)確認(rèn)Comment [p9]: 功能問題，已經(jīng)修改并驗(yàn)證。PICC電銷系統(tǒng)清分功能性能測(cè)試報(bào)告 32 ? ? : ERROR? 錯(cuò)誤原因:該保單的狀態(tài)不是 “保單繳費(fèi)并且已到賬” 。? XML文件被頻繁解析，產(chǎn)生不必要的資源消耗。應(yīng) 用 程 序 性 能 分 析 _支 持 報(bào) 告 _鄧 釗 星 2 劉金華 PICC現(xiàn) 場 支 持 報(bào) 告 (20221222).doc3 張卿 PICC現(xiàn) 場 支 持 報(bào) 告 24 張卿 PICC現(xiàn) 場 支 持 報(bào) 告 2