一、什么是性能測試

新功能上線或切換底層數(shù)據(jù)庫或擴容調(diào)優(yōu)，根據(jù)實際業(yè)務(wù)場景的需要，做必要的性能壓測，收集性能數(shù)據(jù)，作為上線的基準(zhǔn)報告。

性能測試一般分一下幾個階段：

1. 性能測試

     并發(fā)量?。╦meter 并發(fā)線程幾十個，可以選擇 10 個線程），系統(tǒng)各資源使用率低，接口響應(yīng)時間端，系統(tǒng)整體吞吐低。

2. 負載測試

 并發(fā)量適中，系統(tǒng)各資源已趨于高負載，持續(xù)觀察接口的吞吐量、各資源的負載情況。通過對比個資源負載，尋找性能瓶頸。

舉幾個例子：

a. 如果 ECS 負載較高，但是數(shù)據(jù)庫負載較低：

可能的原因：

i. 數(shù)據(jù)庫連接池配置的連接數(shù)較小，大流量還沒到數(shù)據(jù)庫

ii. 各種連接池，比如數(shù)據(jù)庫的、http 連接池等，及 dubbo 線程池大小。

3. 壓力測試

做壓力測試的目的，主要是觀察接口在瞬時大流量過來的情況，接口各性能指標(biāo)的變化，來判斷接口后端服務(wù)及依賴的各中間件是否能承受的住。

二、性能相關(guān)的術(shù)語

1、事務(wù)

用戶發(fā)送請求->服務(wù)器接口請求->服務(wù)器從數(shù)據(jù)庫或其他三方服務(wù)獲取數(shù)據(jù)->生成服務(wù)返回結(jié)果->返回用戶

2、并發(fā)數(shù)

系統(tǒng)同時處理的 Request 數(shù)

3、響應(yīng)時間

客戶端從發(fā)出請求到接收到響應(yīng)總的耗時時間。

QPS（TPS）

4、系統(tǒng)每秒處理的 Query/Transcation Request 數(shù)

QPS(TPS)=并發(fā)數(shù)/響應(yīng)時間

1000/s =并發(fā)數(shù)/0.2s ===》并發(fā)數(shù)=800  

2000/s =并發(fā)數(shù)/0.5s ===》并發(fā)數(shù)= 1000

三、影響性能壓測的因素

1. 壓測客戶端的并發(fā)能力

2. 應(yīng)用系統(tǒng)

a. 池化資源：http connection pool / db connection pool / rabbion

b. 交互數(shù)據(jù)的大小

c. 邏輯：串行邏輯

3. 數(shù)據(jù)庫 

4. 中間件：redis/kafka 規(guī)格及應(yīng)用使用的參數(shù)

三、如何尋找性能瓶頸

1. 首先，要清楚請求鏈路。從壓測機上發(fā)出到響應(yīng)，請求處理需要經(jīng)過或依賴哪些服務(wù)或中間件（同下文的環(huán)節(jié)，方便描述），所以鏈路上各每個環(huán)節(jié)都可能會成為性能瓶頸點。比如請求接口是走域名訪問，勢必會經(jīng)過 nginx 轉(zhuǎn)發(fā)，那么 nginx 也可能會成為性能瓶頸點。

2. 要清楚整條鏈路上各環(huán)節(jié)資源配置。做好鏈路上各環(huán)節(jié)的資源的監(jiān)控，方便及時發(fā)現(xiàn)問題。

3. 尋找性能瓶頸，應(yīng)先從整體到局部排查。首先觀察鏈路上各環(huán)節(jié)的負載情況，如果發(fā)現(xiàn)其中一個環(huán)節(jié)及之后的環(huán)節(jié)負載都很低，那么應(yīng)該是上游領(lǐng)近的節(jié)點處理慢了，此時應(yīng)該重點分析處理慢的節(jié)點。待整個鏈路的各資源（服務(wù)器、數(shù)據(jù)庫或其他中間件）的負載上來了，就需要調(diào)整環(huán)節(jié)內(nèi)部的參數(shù)，比如數(shù)據(jù)庫連接池、http 連接池、dubbo 線程池及隊列等參數(shù)，尋找最優(yōu)參數(shù)值。

四、性能優(yōu)化措施

性能測試的目的是為了解系統(tǒng)的性能以此評估上線部署時所需要多大資源才能滿足業(yè)務(wù)需求。在調(diào)測的過程中，尋找性能瓶頸，發(fā)現(xiàn)性能問題，結(jié)合業(yè)務(wù)場景做優(yōu)化。

1. 讀少寫多的數(shù)據(jù)，接受延遲查詢的數(shù)據(jù)，可以考慮異步寫入。

2. 優(yōu)化各連接池及隊列的大小