4/4性能測試報告范例+性能測試報告

版本

1.概述

1.1.背景

Customer子系統(tǒng)是PSS系統(tǒng)內(nèi)部存儲旅客數(shù)據(jù)的唯一數(shù)據(jù)源；向全渠道，所有接觸點提供高效旅客檔案管理,旅客價值計算服務(wù)，支持航空公司基于旅客價值提供差異化、個性化旅客服務(wù)；Customer子系統(tǒng)是航空公司專屬系統(tǒng)。

本次對CA集群進行性能測試和高可用性測試。

1.2.測試目的

1、驗證Customer集群所能支持的最大性能容量

2、驗證Customer集群的運行穩(wěn)定性

3、驗證Customer集群的高可用性和traveldata數(shù)據(jù)庫解決方案的高可用性

2.測試準(zhǔn)備

2.1.系統(tǒng)架構(gòu)

圖1邏輯架構(gòu)圖

圖2物理架構(gòu)圖

2.2.軟硬件環(huán)境

2.2.1.硬件及底層軟件配置

表2硬件及底層軟件配置表2.2.2.應(yīng)用及中間件配置

表3應(yīng)用及中間件配置表

2.3.測試腳本準(zhǔn)備

表4腳本描述表2.4.時間人員安排

表5時間人員安排表

3.測試執(zhí)行

3.1.容量測試

3.1.1.場景1：Customer容量測試

a)案例描述

表6場景描述

b)結(jié)果描述

圖2總事務(wù)TPS隨vu變化曲線圖

圖3響應(yīng)時間隨vu變化曲線圖

圖4integration服務(wù)器CPU變化曲線圖（10.6.154.172）

圖5server應(yīng)用服務(wù)器CPU變化曲線圖（10.6.154.175）

圖6數(shù)據(jù)庫服務(wù)器CPU變化曲線圖（10.6.184.208）

表7性能指標(biāo)統(tǒng)計及資源使用情況

場景1開始后，Customer事務(wù)TPS隨vu數(shù)增加而同步增加。場景運行至6分04秒時，共啟動了85個vu，TPS增加至2550個/秒，平均響應(yīng)時間增加至45毫秒。此時3臺integration服務(wù)器的CPU利用率平均值14.9%，3臺server服務(wù)器的CPU利用率平均值為22.6%，數(shù)據(jù)庫主節(jié)點的CPU利用率為18.7%。此后再增加vu，TPS不再有明顯增長，響應(yīng)時間繼續(xù)增加，可以判斷6分04秒左右時，系統(tǒng)呈現(xiàn)性能拐點態(tài)勢。達到拐點之后，系統(tǒng)性能基本穩(wěn)定。

3.2.疲勞測試

3.2.1.場景2：Customer疲勞測試

a)案例描述

表8場景描述

b)結(jié)果描述

圖7總事務(wù)TPS變化曲線圖

圖8響應(yīng)時間變化曲線圖（10.6.50.81）

圖9integration服務(wù)器CPU變化曲線圖（10.6.154.172）

圖10server服務(wù)器CPU變化曲線圖（10.6.154.175）

圖11數(shù)據(jù)庫服務(wù)器CPU變化曲線圖（10.6.184.208）

表9性能指標(biāo)統(tǒng)計及資源使用情況

共啟動了30個vu，向MQ隊列發(fā)送Customer查詢請求，TPS平均值為1197，平均響應(yīng)時間為24毫秒。整個場景執(zhí)行過程中，應(yīng)用服務(wù)器的內(nèi)存使用方面：free+buffer+cached總量基本保持不變，swap交換區(qū)始終未被使用。Integration三臺節(jié)點的CPU利用率平均值為7.3%，server三臺節(jié)點的CPU利用率平均值為11.5%，數(shù)據(jù)庫主節(jié)點的CPU利用率為8.9%.超時交易占總交易的比例為0.02%。

3.3.高可用性測試

3.3.1.場景3：integration高可用測試

表10integration高可用性測試

3.3.2.場景4：Server高可用性測試

表11server高可用性測試3.3.3.場景5：traveldata高可用性測試

表12高可用性測試業(yè)務(wù)分析表

4.測試結(jié)果分析

4.1.容量測試

在當(dāng)前測試環(huán)境下，對系統(tǒng)發(fā)送customer查詢請求，系統(tǒng)支持的最大TPS數(shù)為2550個/秒，響應(yīng)時間為45毫秒。此時3臺integration服務(wù)器的CPU利用率平均值14.9%，3臺server服務(wù)器的CPU利用率平均值為22.6%，數(shù)據(jù)庫主節(jié)點的CPU利用率為18.7%。此后再增加vu，TPS不再有明顯增長，響應(yīng)時間持續(xù)增加，可以判斷6分04秒左右時，系統(tǒng)呈現(xiàn)性能拐點態(tài)勢。達到拐點之后，系統(tǒng)性能基本穩(wěn)定。由于本地網(wǎng)絡(luò)流量已經(jīng)達到了15MB/s，基本達到了壓力機最大帶寬，可能是導(dǎo)致TPS無法進一步增加的性能瓶頸。

4.2.疲勞測試

在當(dāng)前測試環(huán)境下，系統(tǒng)可以在Customer查詢請求的TPS為1200個/秒的壓力下較平

穩(wěn)地運行12個小時，事務(wù)平均響應(yīng)時間為24毫秒。Integration三臺節(jié)點的CPU利用率平均值為7.3%，server三臺節(jié)點的CPU利用率平均值為11.5%，數(shù)據(jù)庫主節(jié)點的CPU利用率為8.9%.應(yīng)用服務(wù)器的內(nèi)存使用方面，free+buffer+cached總量基本保持不變，swap交換區(qū)始終未被使用。超時交易占總交易的比例為0.02%。

4.3.高可用性測試

1、Integration高可用性測試：當(dāng)發(fā)生integration核心應(yīng)用進程丟失，服務(wù)器重啟和單網(wǎng)卡故障時，Customer查詢業(yè)務(wù)的TPS和響應(yīng)時間基本不受影響，Customer服務(wù)持續(xù)可用。

2、Server高可用性測試：當(dāng)發(fā)生server核心應(yīng)用進程丟失和單網(wǎng)卡故障時，Customer查詢業(yè)務(wù)的TPS和響應(yīng)時間基本不受影響，Customer服務(wù)持續(xù)可用；當(dāng)發(fā)生服務(wù)器重啟故障時，TPS下降至0，整個集群服務(wù)不可用，持續(xù)時間約為40秒。40秒后，系統(tǒng)會將發(fā)生節(jié)點故障的server進行隔離，TPS和響應(yīng)時間恢復(fù)至故障前水平。在重啟jboss服務(wù)時，jboss尚未完全啟動成功即開始接收請求，造成notffp的報錯，jboss成功啟動后不再有notffp的報錯。當(dāng)發(fā)生主節(jié)點server故障之后又發(fā)生integration單節(jié)點故障時，當(dāng)1臺server出現(xiàn)故障后，整個集群仍然可以訪問，此時如果再出現(xiàn)任意1臺integration不可用，那么對這臺integration重啟jboss之后，則該integration無法將請求發(fā)送至另外2臺服務(wù)正常的server上去。

3、Traveldata高可用性測試：當(dāng)發(fā)生數(shù)據(jù)庫主節(jié)點的集群軟件異常、硬件宕機、服務(wù)器hang死、應(yīng)用網(wǎng)故障、數(shù)據(jù)網(wǎng)故障、殺死數(shù)據(jù)庫主進程、殺死數(shù)據(jù)庫子進程故障時，數(shù)據(jù)庫主節(jié)點會切換至數(shù)據(jù)庫備1節(jié)點，造成一段時間內(nèi)TPS下降至0，服務(wù)不可用，切換完成后TPS和響應(yīng)時間恢復(fù)正常。Customer查詢的不可訪問時間為集群軟件異常45秒、硬件宕機45秒、服務(wù)器hang死54秒、應(yīng)用網(wǎng)故障50秒、數(shù)據(jù)網(wǎng)故障12秒、殺死數(shù)據(jù)庫主進程45秒、殺死數(shù)據(jù)庫子進程故障30秒。當(dāng)發(fā)生數(shù)據(jù)庫主節(jié)點應(yīng)用網(wǎng)單網(wǎng)卡故障、數(shù)據(jù)網(wǎng)單網(wǎng)卡故障，數(shù)據(jù)庫備節(jié)點的集群軟件異常、硬件宕機、服務(wù)器hang死、應(yīng)用網(wǎng)故障、數(shù)據(jù)網(wǎng)故障、殺死數(shù)據(jù)庫主進程、殺死數(shù)據(jù)庫子進程故障，數(shù)據(jù)庫三節(jié)點腦裂故障時，Customer查詢的TPS和響應(yīng)時間不會受到影響，應(yīng)用服務(wù)始終可用。

5.主要問題

1、當(dāng)發(fā)生server服務(wù)器故障時（通過init6指令使該應(yīng)用節(jié)點故障），TPS下降至0，整個集群服務(wù)不可用，持續(xù)時間約為40秒。40秒后，系統(tǒng)會將發(fā)生節(jié)點故障的server進行隔離，TPS和響應(yīng)時間恢復(fù)至故障前水平，與預(yù)期結(jié)果不一致，存在一個2級缺陷；

2、當(dāng)發(fā)生主節(jié)點server和integration雙點故障時（先使主節(jié)點175失效，再使任意一

臺integration失效），對這臺integration重啟jboss之后，該integration無法將請求發(fā)送至另外2臺服務(wù)正常的server上去，原因是當(dāng)前integration的配置文件中只和175一個server節(jié)點連接，與預(yù)期結(jié)果不一致，存在一個2級缺陷。

6.風(fēng)險分析及建議

1、當(dāng)server節(jié)點重啟jboss時，由于jboss尚未完全啟動完畢即開始接收請求，造成notffp的報錯，jboss成功啟動后不再有notffp的報錯發(fā)生，請研發(fā)和運行同事注意此風(fēng)險的影響；