1.前提概念
平時常用的性能測試：api性能測試+場景性能測試；今天就說一說api性能測試
2.如何進行性能測試？
需求：對某api進行性能測試，看看最大承受的並發數，分析下圖表
分析：
錯誤思路：當我們接到這個需求的時候，很多人不管三七二十一，先把接口寫起來，然后給他個1000個並發，壓倒報錯為止，但是實際上你知道怎么去壓測么，怎么分析TPS么？怎么找到最大並發數？怎么分析報錯請求？那我們到底怎么分析呢
分析思路：
- 首先，api測試嘛，我先把api腳本給調試好，
- 然后加各種圖表分析報告
- 之后設計各種場景，例如：設計場景1：並發20個用戶，每秒增加2個用戶，請求2000次；場景2：分析TPS，並發200個用戶，每秒增加20個用戶，請求2000次。。。。。。。依次類推
3.性能指標
在我們實戰前，先了解一下性能指標：
通常情況下，一般我們可能不會添加其他插件的前提下，都會添加一個監聽器->聚合報告，那么聚合報告到底用來做什么的呢？
我們可以看見：average(平均響應時間) median,90% 95% min (最小) ，max(最大) 都是跟時間有關系，所以我們可以側面理解為，聚合報告，大部分就是監控整個訪問時間
其他：
sampler:一共完成了多少請求
Throughput:吞吐量，默認情況下標識每秒處理的請求書，可以指服務器處理能力，tps越高說明服務器處理能力越好
4.實戰
1.准備腳本
場景1：並發20個用戶，每秒增加2個用戶，請求2000次，
線程組：相當於並發多少用戶
Ramp-UP: 每秒增加2個用戶, 20/2=10 ,所以填10，意思是1秒內往上加2個用戶
循環：請求2000次；計算：20000/線程組（20）= 100
2.腳本分析
分析一波：
首先右上角：3/20 : 當前線程往上加，最大並發數是20，3是當前線程數
看下報告：
1.sampler:當前一共2000個請求
2吞吐量遠遠大於20個線程組數，tps很高，說明服務器完全能承受；
3.場景二腳本分析：
場景：並發200個用戶，每秒增加20個用戶，請求20000次
分析：
1.首先錯誤率很高，就能看出很多了
2.吞吐量小於當前並發數，說明200個並發數不適合，已經不能夠承受了
3.為了找到最合適的並發數。可以設計不同場景，例如用二分法，100個並發用戶，150個並發用戶之類，
5.總結
其實性能測試遠遠不止於這些，但是從基礎的吞吐量，以及並發數，我們就可以分析很多問題了，如果設計服務器上監控，那么又是一個概念了。我覺得從這篇文章至少我們可以堅持api性能的最合理的並發數，以及tps. tps越高說明性能越好。若壓測的機器性能很好，出現吞吐量小於並發數，說明並發數不能再增加了，可以慢慢減下來，找到合理並發數
ps: 有錯誤歡迎指出來，虛心請教。