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