目錄
如何找到並發數、平均響應時間、tps的最佳平衡點？
1、先回顧下基礎，性能測試常用的指標有三個：並發、響應時間、tps
- 並發：跑道里參加賽跑的人數（這里的並發是廣義的並發，即同一個時間段內對系統發起的請求數量）
- 響應時間：也就是平均每個事務的處理時間
- tps：每秒處理的事務數
2、需求指標：分為單指標和多指標
- 單指標：一般是單測試tps，或者根據並發測試響應時間，或者根據響應時間測試並發，只考慮單指標的很少
- 多指標：要同時考慮多個指標，比如tps + 響應時間(<1s)
3、 找到這三個指標同時最佳值的點，
不能只追求並發數大，而忽略tps，所以，這是一個多指標性能需求，假設是這樣的：要求響應時間1秒以內，並發數要盡可能的多，tps要盡可能的大。（基礎篇中提到的拐點）
是不是依舊有點懵逼？先畫一個簡單的示意圖，方便大家理解（隨手畫的，大家能理解就ok）：
- 隨着並發數增加，響應時間肯定是越來越高，所以，上面紅線是響應時間；
- 隨着並發數增加，tps是先升高到峰值，然后下降（也可能是一直平穩，或者平穩一段時間再下降），所以，上面藍線是tps；
4、該怎么去找這個最佳平衡點呢？
- 盡可能多的做不同並發數下的壓測，記錄下響應時間（1s以內）和最大tps，當然，服務器端，各個服務器的資源利用率在可接受范圍內（每個公司不一樣，一般是85-90%）；
- 然后根據獲取到的不同並發下的指標數據（並發數、tps、響應時間），畫出上圖，關注右側的交點，即tps下降的地方和響應時間的交點，這個點的tps最大，如果響應時間在1s以內，此時並發數也是比較大的，這個點就可以認為是三個指標都不錯的平衡點（當然，我這里把tps放在第一位優先考慮了，這個就看大家最在乎哪個指標了，排個優先級）；如果響應時間大於1s，最佳平衡點就往左找，找到響應時間為1秒的點，此時對應的tps和並發值，就是最佳平衡點。總之，測試采樣越多，獲取的平衡點就越准確。
- 另外，如果是用loadrunner或jmeter作為並發工具，並發過程中是可以增加或者減少並發用戶數的，就不用必須壓完一次，再調整並發數繼續壓，但是，並發過程中調整了並發數，還是要盡可能跑久一點，比如10-15min。
篇外話題: TPS和QPS的區別
TPS：Transactions Per Second
意思是每秒事務數，一個事務是指一個客戶機向服務器發送請求然后服務器做出反應的過程。客戶機在發送請求時開始計時，收到服務器響應后結束計時，以此來計算使用的時間和完成的事務個數。
每個事務包括了如下3個過程：如果每秒能夠完成N次這三個過程，tps就是N；有時，可能會將多個請求定義為一個事務，那么，完成一次這幾個請求，就算一個tps。
- 用戶請求服務器
- 服務器自己的內部處理（包含應用服務器、數據庫服務器等）
- 服務器返回給用戶
QPS：Queries Per Second
意思是每秒查詢率，是一台服務器每秒能夠響應的查詢次數，是對一個特定的查詢服務器（比如是讀寫分離的架構，就是讀的服務器）在規定時間內所處理流量多少的衡量標准
區別
- 如果對一個頁面請求一次，形成一個tps，但一次頁面請求，可能產生多次對服務器的請求（頁面上有很多資源，比如圖片等），服務器對這些請求，就可計入“qps”之中；
- 但是，如今的項目基本上都是前后端分離的，性能也分為前端性能和后端性能，通常默認是后端性能，即服務端性能，也就是對服務端接口做壓測
- 如果是對一個接口（單場景）壓測，且這個接口內部不會再去請求其它接口，那么tps=qps，否則，tps≠qps
- 如果是對多個接口（混合場景）壓測，不加事務控制器，jmeter會統計每個接口的tps，而混合場景是要測試這個場景的tps，顯然這樣得不到混合場景的tps，所以，要加了事物控制器，結果才是整個場景的tps。
- jmeter聚合報告中，Throughput是用來衡量請求的吞吐量，也就是tps（單接口統計)
支持原創：轉自-->https://www.cnblogs.com/uncleyong/p/11059556.html
https://www.cnblogs.com/uncleyong/p/11543488.html