【正文】 U 使用率不應(yīng)該超過 60%。? 線程數(shù)設(shè)置過高，不斷不能提高應(yīng)用系統(tǒng)的工作效率，相反的還會(huì)降低系統(tǒng)的功能效率，并產(chǎn)生很高的 CPU 利用率。根據(jù)上述總結(jié)，可以畫出下圖所示 CPU%、線程數(shù)以及程序 TPS 值之間的關(guān)系。TPSCPU%線程數(shù)數(shù)值 Queue 隊(duì)列的處理情況根據(jù) TI 流程 20220 數(shù)據(jù)量測試和 TF 流程 20220 數(shù)據(jù)量測試兩個(gè)測試結(jié)果，來分析清分模塊中三個(gè)隊(duì)列的業(yè)務(wù)處理能力。PICC 電銷系統(tǒng)清分功能性能測試報(bào)告 28 從圖中可以發(fā)現(xiàn)：? 三個(gè)隊(duì)列中 queueR 的處理能力最強(qiáng)，遠(yuǎn)遠(yuǎn)高于另外兩個(gè)隊(duì)列。TPS 高達(dá) 200以上。? queueData 隊(duì)列處理能力最弱，TPS 值為 20 左右。? PNOqueue 隊(duì)列的處理能力居中， TPS 值為 25 左右。建議項(xiàng)目組對三個(gè)隊(duì)列的技術(shù)實(shí)現(xiàn)形式和業(yè)務(wù)邏輯進(jìn)行分析。找出三個(gè)隊(duì)列之間差距的原因。本次性能測試的其中一個(gè)目的是“評估當(dāng)前系統(tǒng)容量是否滿足業(yè)務(wù)未來一年發(fā)展的需要” 。預(yù)估明年每日新增的投保單數(shù)據(jù)量為 2 萬筆?？梢酝ㄟ^一個(gè)簡單的計(jì)算來驗(yàn)證目前測試出系統(tǒng)的容量是否滿足未來 2 萬筆的需要。每日投保單數(shù)據(jù)量：20220每日工作時(shí)間：8 小時(shí)根據(jù)軟件測試中的 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)過壓測得出的 PNOqueue 的 TPS 值為 25 左右。注：以下段落為 Weblogic 工程師對 queueData 和 pnoQueue 兩個(gè)隊(duì)列的分析建議。通過監(jiān)控對 queueData 的線程進(jìn)行 dump 分析，發(fā)現(xiàn) 15 個(gè)線程中有 9 個(gè)在等待或者執(zhí)行調(diào)用分公司平臺(tái)的 WebService 的結(jié)果，有 3 個(gè)在從數(shù)據(jù)庫讀取數(shù)據(jù)。到了業(yè)務(wù)最高峰的時(shí)候，15 個(gè)線程全部在等待 WebService 的結(jié)果。從線程使用時(shí)間來分析，對 WebService調(diào)用結(jié)果的等待占用了 60%以上的運(yùn)行時(shí)間。如圖所示：PICC 電銷系統(tǒng)清分功能性能測試報(bào)告 29 從上分析可以看出，WebService 的結(jié)果返回占用時(shí)間最長，是整個(gè)隊(duì)列 2290 這個(gè)JMS Client 端最大的時(shí)間消耗者。如果能夠?qū)?WebService 進(jìn)行優(yōu)化，將能夠大大縮短業(yè)務(wù)執(zhí)行時(shí)間，同時(shí)也能夠大大提高應(yīng)用程序的性能。pnoQueue 的線程進(jìn)行 dump 分析：15 個(gè)線程中有 1113 個(gè)從數(shù)據(jù)庫讀取數(shù)據(jù)，占用了73%到 87%的線程資源。從線程使用時(shí)間來分析，對數(shù)據(jù)庫返回結(jié)果的等待占用了 60%以上的運(yùn)行時(shí)間，如下圖所示：從上分析可以看出，數(shù)據(jù)庫查詢結(jié)果返回占用時(shí)間最長，是 pnoQueue 隊(duì)列這個(gè) JMS Client 端最大的時(shí)間消耗者。如果能夠?qū)?shù)據(jù)庫查詢性能進(jìn)行優(yōu)化，將能夠大大縮短業(yè)務(wù)執(zhí)行時(shí)間，同時(shí)也能夠大大提高應(yīng)用程序的性能。PICC 電銷系統(tǒng)清分功能性能測試報(bào)告 30 6 測試風(fēng)險(xiǎn) 測試環(huán)境相關(guān)? 測試環(huán)境與生產(chǎn)環(huán)境配置及使用狀況存在較大差異，測試結(jié)果僅能說明在目前測試環(huán)境下的性能表現(xiàn)。與實(shí)際生產(chǎn)環(huán)境運(yùn)行時(shí)的性能表現(xiàn)存在差異。? 測試環(huán)境所在服務(wù)器同時(shí)運(yùn)行多個(gè)系統(tǒng)，系統(tǒng)整體負(fù)荷較高。在執(zhí)行性能測試時(shí)只能監(jiān)控系統(tǒng)全局的資源消耗，無法準(zhǔn)確判斷被測系統(tǒng)的資源消耗情況。? 數(shù)據(jù)庫服務(wù)器同時(shí)運(yùn)行多個(gè)實(shí)例，并且被測數(shù)據(jù)庫所在實(shí)例也有另外的程序在運(yùn)行，影響判斷數(shù)據(jù)庫是否存在性能瓶頸。? 在測試執(zhí)行過程中，無法監(jiān)控分公司服務(wù)器的運(yùn)行情況，分公司若出現(xiàn)異?；蛱幚磔^慢，將會(huì)影響性能測試的測試結(jié)果。? 無法監(jiān)控測試環(huán)境中的網(wǎng)絡(luò)資源使用情況，網(wǎng)絡(luò)環(huán)境異常也會(huì)造成測試結(jié)果不準(zhǔn)確。? 由于測試環(huán)境存在和生產(chǎn)環(huán)境共用網(wǎng)絡(luò)帶寬和服務(wù)器系統(tǒng)資源的情況，正常生產(chǎn)業(yè)務(wù)繁忙與空閑期，也會(huì)對性能測試的結(jié)果有影響。 測試執(zhí)行相關(guān)? 監(jiān)控隊(duì)列中消息數(shù)量情況的工具為每 5 秒收集一次，所監(jiān)控的消息消費(fèi)時(shí)間存在177。5 秒的誤差。? 使用 sarmon 監(jiān)控服務(wù)器操作系統(tǒng)時(shí)，只能監(jiān)控全局的資源使用情況。? 所測業(yè)務(wù)流程涉及與分中心的交互，由于無法監(jiān)控到分中心的處理情況，僅監(jiān)控總中心處 PNOqueue、queueR、queueData 三個(gè)隊(duì)列的運(yùn)行狀況。? 總中心與分中心交互過程中所消耗的時(shí)間與網(wǎng)絡(luò)環(huán)境、分中心處理能力存在較大聯(lián)系，本次測試并未監(jiān)控整個(gè)業(yè)務(wù)流程所消耗的全部時(shí)間。而著重監(jiān)控總中心隊(duì)列所消耗的時(shí)間。? 由于 TF 和 PI 流程同時(shí)觸發(fā)，整個(gè)過程涉及總中心與分中心的交互，涉及總中心三個(gè)消息隊(duì)列同時(shí)運(yùn)轉(zhuǎn)。無法同是監(jiān)控三個(gè)隊(duì)列的運(yùn)行狀態(tài)，考慮Comment [p2]: 與開發(fā)確認(rèn)此問題不用修復(fù)。Comment [p3]: 測試環(huán)境數(shù)據(jù)庫連接數(shù)是 600。由于與生產(chǎn)服務(wù)器共享硬件資源，連接數(shù)不能繼續(xù)增大，測試過程中出現(xiàn)過多次連接數(shù)滿的情況。在數(shù)據(jù)庫中可以觀察到大量INACTIVE的連接仍與數(shù)據(jù)庫相連，請核心與核保排查此問題。確認(rèn)連接無法自動(dòng)斷開的原因。Comment [p4]: 空指針異常Comment [p5]: 連接數(shù)滿導(dǎo)致數(shù)據(jù)庫連接異常PICC電銷系統(tǒng)清分功能性能測試報(bào)告 31 到 PI流程與 TI流程流程，故 TF測試時(shí)，僅監(jiān)控了 PNOqueue和queueData兩個(gè)隊(duì)列的處理情況。7 測試結(jié)論根據(jù)本文前面結(jié)果分析的分析，可以得出如下測試結(jié)論：? 清分功能中涉及到的 PNOqueue、queueR 和 queueData三個(gè)隊(duì)列，其中queueR的工作效率最高，PNOqueue 和 queueData處理能力相對較弱。通過Weblogic工程師的分析初步判斷這兩個(gè)隊(duì)列慢的原因是由于調(diào)用 WebService和數(shù)據(jù)庫查詢較慢。? 就目前測試環(huán)境測算出的系統(tǒng)容量基本可以滿足 PICC未來一年業(yè)務(wù)量的發(fā)展。即每日 20220筆新增投保單。 （測試計(jì)算出 PNOqueue的 TPS為 25，滿足業(yè)務(wù)需要的 TPS值 14）? 根據(jù)目前的測試環(huán)境無法給出生產(chǎn)環(huán)境所需要的線程數(shù)配置大小，但是通過測試可以得出：增加清分系統(tǒng)的線程數(shù)，會(huì)提高應(yīng)用系統(tǒng)的工作效率，但是增加線程數(shù)會(huì)對 CPU產(chǎn)生更大的開銷。 （詳情請看線程數(shù)對系統(tǒng)性能的影響）8 附件本次測試主要發(fā)現(xiàn)以下幾個(gè)問題：? : ORA00001: unique constraint：主鍵唯一性約束，由于清分系統(tǒng)的生成流水號(hào)規(guī)則只精確到毫秒級別，導(dǎo)致測試過程中出現(xiàn)不同的記錄使用同樣的流水號(hào)。? : Pool not open：連接池未打開，主要由于數(shù)據(jù)庫連接數(shù)已滿，導(dǎo)致應(yīng)用程序創(chuàng)建連接時(shí)無法正常連接。? ? : Io 異常: Connection refusedComment [p6]: 連接數(shù)滿導(dǎo)致數(shù)據(jù)庫連接異常Comment [p7]: 請申國強(qiáng)確認(rèn)Comment [p8]: 請申國強(qiáng)確認(rèn)Comment [p9]: 功能問題，已經(jīng)修改并驗(yàn)證。Comment [p10]: 功能問題，已經(jīng)修改并驗(yàn)證。PICC電銷系統(tǒng)清分功能性能測試報(bào)告 32 ? ? : ERROR? 錯(cuò)誤原因:該保單的狀態(tài)不是 “保單繳費(fèi)并且已到賬” 。? 清分模塊在從隊(duì)列中取消息時(shí)，未進(jìn)行數(shù)據(jù)庫連接狀態(tài)的判斷，導(dǎo)致數(shù)據(jù)庫異常時(shí)，消息大量丟失。? XML文件被頻繁解析，產(chǎn)生不必要的資源消耗。 問題具體優(yōu)化情況見附件：問 題 跟 蹤 清 分 .xls BEA工程師的監(jiān)控報(bào)告序號(hào) 工程師 文檔1 鄧釗星 PICC_電 銷 系 統(tǒng) 清 分功 能 壓 力 測 試 amp。應(yīng) 用 程 序 性 能 分 析 _支 持 報(bào) 告 _鄧 釗 星 2 劉金華 PICC現(xiàn) 場 支 持 報(bào) 告 (20221222).doc3 張卿 PICC現(xiàn) 場 支 持 報(bào) 告 24 張卿 PICC現(xiàn) 場 支 持 報(bào) 告 2