目錄如何找到并發(fā)數(shù)、平均響應(yīng)時間、tps的最佳平衡點？1、先回顧下基礎(chǔ)，性能測試常用的指標有三個：并發(fā)、響應(yīng)時間、tps2、需求指標：分為單指標和多指標3、 找到這三個指標同時最佳值的點，4、該怎么去找這個最佳平衡點呢？篇外話題: TPS和QPS的區(qū)別TPS：Transactions Per SecondQPS：Queries Per Second區(qū)別

如何找到并發(fā)數(shù)、平均響應(yīng)時間、tps的最佳平衡點？

1、先回顧下基礎(chǔ)，性能測試常用的指標有三個：并發(fā)、響應(yīng)時間、tps

并發(fā)：跑道里參加賽跑的人數(shù)（這里的并發(fā)是廣義的并發(fā)，即同一個時間段內(nèi)對系統(tǒng)發(fā)起的請求數(shù)量）
響應(yīng)時間：也就是平均每個事務(wù)的處理時間
tps：每秒處理的事務(wù)數(shù)

2、需求指標：分為單指標和多指標

單指標：一般是單測試tps，或者根據(jù)并發(fā)測試響應(yīng)時間，或者根據(jù)響應(yīng)時間測試并發(fā)，只考慮單指標的很少
多指標：要同時考慮多個指標，比如tps + 響應(yīng)時間(<1s)

3、 找到這三個指標同時最佳值的點，

不能只追求并發(fā)數(shù)大，而忽略tps，所以，這是一個多指標性能需求，假設(shè)是這樣的：要求響應(yīng)時間1秒以內(nèi)，并發(fā)數(shù)要盡可能的多，tps要盡可能的大。（基礎(chǔ)篇中提到的拐點）

是不是依舊有點懵逼？先畫一個簡單的示意圖，方便大家理解（隨手畫的，大家能理解就ok）：

隨著并發(fā)數(shù)增加，響應(yīng)時間肯定是越來越高，所以，上面紅線是響應(yīng)時間；
隨著并發(fā)數(shù)增加，tps是先升高到峰值，然后下降（也可能是一直平穩(wěn)，或者平穩(wěn)一段時間再下降），所以，上面藍線是tps；

4、該怎么去找這個最佳平衡點呢？

盡可能多的做不同并發(fā)數(shù)下的壓測，記錄下響應(yīng)時間（1s以內(nèi)）和最大tps，當然，服務(wù)器端，各個服務(wù)器的資源利用率在可接受范圍內(nèi)（每個公司不一樣，一般是85-90%）；
然后根據(jù)獲取到的不同并發(fā)下的指標數(shù)據(jù)（并發(fā)數(shù)、tps、響應(yīng)時間），畫出上圖，關(guān)注右側(cè)的交點，即tps下降的地方和響應(yīng)時間的交點，這個點的tps最大，如果響應(yīng)時間在1s以內(nèi)，此時并發(fā)數(shù)也是比較大的，這個點就可以認為是三個指標都不錯的平衡點（當然，我這里把tps放在第一位優(yōu)先考慮了，這個就看大家最在乎哪個指標了，排個優(yōu)先級）；如果響應(yīng)時間大于1s，最佳平衡點就往左找，找到響應(yīng)時間為1秒的點，此時對應(yīng)的tps和并發(fā)值，就是最佳平衡點?？傊?，測試采樣越多，獲取的平衡點就越準確。
另外，如果是用loadrunner或jmeter作為并發(fā)工具，并發(fā)過程中是可以增加或者減少并發(fā)用戶數(shù)的，就不用必須壓完一次，再調(diào)整并發(fā)數(shù)繼續(xù)壓，但是，并發(fā)過程中調(diào)整了并發(fā)數(shù)，還是要盡可能跑久一點，比如10-15min。

篇外話題: TPS和QPS的區(qū)別

TPS：Transactions Per Second

意思是每秒事務(wù)數(shù)，一個事務(wù)是指一個客戶機向服務(wù)器發(fā)送請求然后服務(wù)器做出反應(yīng)的過程?？蛻魴C在發(fā)送請求時開始計時，收到服務(wù)器響應(yīng)后結(jié)束計時，以此來計算使用的時間和完成的事務(wù)個數(shù)。

每個事務(wù)包括了如下3個過程：如果每秒能夠完成N次這三個過程，tps就是N；有時，可能會將多個請求定義為一個事務(wù)，那么，完成一次這幾個請求，就算一個tps。

用戶請求服務(wù)器
服務(wù)器自己的內(nèi)部處理（包含應(yīng)用服務(wù)器、數(shù)據(jù)庫服務(wù)器等）
服務(wù)器返回給用戶

QPS：Queries Per Second

意思是每秒查詢率，是一臺服務(wù)器每秒能夠響應(yīng)的查詢次數(shù)，是對一個特定的查詢服務(wù)器（比如是讀寫分離的架構(gòu)，就是讀的服務(wù)器）在規(guī)定時間內(nèi)所處理流量多少的衡量標準

區(qū)別

如果對一個頁面請求一次，形成一個tps，但一次頁面請求，可能產(chǎn)生多次對服務(wù)器的請求（頁面上有很多資源，比如圖片等），服務(wù)器對這些請求，就可計入“qps”之中；
但是，如今的項目基本上都是前后端分離的，性能也分為前端性能和后端性能，通常默認是后端性能，即服務(wù)端性能，也就是對服務(wù)端接口做壓測

如果是對一個接口（單場景）壓測，且這個接口內(nèi)部不會再去請求其它接口，那么tps=qps，否則，tps≠qps
如果是對多個接口（混合場景）壓測，不加事務(wù)控制器，jmeter會統(tǒng)計每個接口的tps，而混合場景是要測試這個場景的tps，顯然這樣得不到混合場景的tps，所以，要加了事物控制器，結(jié)果才是整個場景的tps。
jmeter聚合報告中，Throughput是用來衡量請求的吞吐量，也就是tps（單接口統(tǒng)計)

支持原創(chuàng)：轉(zhuǎn)自-->https://www.cnblogs.com/uncleyong/p/11059556.html
https://www.cnblogs.com/uncleyong/p/11543488.html

總結(jié)

以上是生活随笔為你收集整理的如何找到并发数、平均响应时间、tps的最佳平衡点？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。