知識分享|如何做好服務 API 的性能壓力測試
發(fā)布時間：2023-08-08 13:51:46
一、什么是性能測試
新功能上線或切換底層數(shù)據(jù)庫或擴容調優(yōu)，根據(jù)實際業(yè)務場景的需要，做必要的性能壓測，收集性能數(shù)據(jù)，作為上線的基準報告。
性能測試一般分一下幾個階段：
1. 性能測試
并發(fā)量?。╦meter 并發(fā)線程幾十個，可以選擇 10 個線程），系統(tǒng)各資源使用率低，接口響應時間端，系統(tǒng)整體吞吐低。
2. 負載測試
并發(fā)量適中，系統(tǒng)各資源已趨于高負載，持續(xù)觀察接口的吞吐量、各資源的負載情況。通過對比個資源負載，尋找性能瓶頸。
舉幾個例子：
a. 如果 ECS 負載較高，但是數(shù)據(jù)庫負載較低：
可能的原因：
i. 數(shù)據(jù)庫連接池配置的連接數(shù)較小，大流量還沒到數(shù)據(jù)庫
ii. 各種連接池，比如數(shù)據(jù)庫的、http 連接池等，及 dubbo 線程池大小。
3. 壓力測試
做壓力測試的目的，主要是觀察接口在瞬時大流量過來的情況，接口各性能指標的變化，來判斷接口后端服務及依賴的各中間件是否能承受的住。
二、性能相關的術語
1、事務
用戶發(fā)送請求->服務器接口請求->服務器從數(shù)據(jù)庫或其他三方服務獲取數(shù)據(jù)->生成服務返回結果->返回用戶
2、并發(fā)數(shù)
系統(tǒng)同時處理的 Request 數(shù)
3、響應時間
客戶端從發(fā)出請求到接收到響應總的耗時時間。
QPS（TPS）
4、系統(tǒng)每秒處理的 Query/Transcation Request 數(shù)
QPS(TPS)=并發(fā)數(shù)/響應時間
1000/s =并發(fā)數(shù)/0.2s ===》并發(fā)數(shù)=800
2000/s =并發(fā)數(shù)/0.5s ===》并發(fā)數(shù)= 1000
三、影響性能壓測的因素
1. 壓測客戶端的并發(fā)能力
2. 應用系統(tǒng)
a. 池化資源：http connection pool / db connection pool / rabbion
b. 交互數(shù)據(jù)的大小
c. 邏輯：串行邏輯
3. 數(shù)據(jù)庫
4. 中間件：redis/kafka 規(guī)格及應用使用的參數(shù)
三、如何尋找性能瓶頸
1. 首先，要清楚請求鏈路。從壓測機上發(fā)出到響應，請求處理需要經過或依賴哪些服務或中間件（同下文的環(huán)節(jié)，方便描述），所以鏈路上各每個環(huán)節(jié)都可能會成為性能瓶頸點。比如請求接口是走域名訪問，勢必會經過 nginx 轉發(fā)，那么 nginx 也可能會成為性能瓶頸點。
2. 要清楚整條鏈路上各環(huán)節(jié)資源配置。做好鏈路上各環(huán)節(jié)的資源的監(jiān)控，方便及時發(fā)現(xiàn)問題。
3. 尋找性能瓶頸，應先從整體到局部排查。首先觀察鏈路上各環(huán)節(jié)的負載情況，如果發(fā)現(xiàn)其中一個環(huán)節(jié)及之后的環(huán)節(jié)負載都很低，那么應該是上游領近的節(jié)點處理慢了，此時應該重點分析處理慢的節(jié)點。待整個鏈路的各資源（服務器、數(shù)據(jù)庫或其他中間件）的負載上來了，就需要調整環(huán)節(jié)內部的參數(shù)，比如數(shù)據(jù)庫連接池、http 連接池、dubbo 線程池及隊列等參數(shù)，尋找最優(yōu)參數(shù)值。
四、性能優(yōu)化措施
性能測試的目的是為了解系統(tǒng)的性能以此評估上線部署時所需要多大資源才能滿足業(yè)務需求。在調測的過程中，尋找性能瓶頸，發(fā)現(xiàn)性能問題，結合業(yè)務場景做優(yōu)化。
1. 讀少寫多的數(shù)據(jù)，接受延遲查詢的數(shù)據(jù)，可以考慮異步寫入。
2. 優(yōu)化各連接池及隊列的大小
