然后我們再來看性能測試的指標是怎么來的呢？

1、產品和運營要給出業務需求：

這個服務，在多長時間段，多少人會訪問

2、性能要求上，通常情況下的APP或者web應該如何？

一般情況下通用的標準是頁面顯示時間預判：

頁面響應時間2、5、8原理(用戶進入服務2s內要展示完所有內容，超過5秒用戶就無法忍受了，超過8秒就沒有人再等了，直接關閉服務)

頁面響應時間3、5、10原理

這里包括了頁面的渲染時間+資源文件的載入時間+接口的獲取時間，那么在這個條件下，壓測的平均響應時間也要在這個時間之內

怎么通過業務量來計算TPS多少合適呢？

案例1，秒殺型算法

案例的業務量要求

某業務，類似秒殺型，用戶估算有2W左右，每個用戶平均請求2次接口(比如查詢用戶信息接口、查詢業務接口)， 這些用戶大概率會在2分鐘內會訪問我們的系統，業務要保證用戶2s能打開頁面

TPS的分析

TPS是系統每秒鐘處理的任務數量，給定了業務場景，我們就需要先計算出每秒需要系統處理多少任務，從而反推在壓力測試的時候，需要多大的TPS了

首先，整個系統的總請求數=用戶(2W)* 每個用戶請求數(2次)= 40000次

其次，每秒要求處理的請求數=總請求數/時間(切換到秒) 即約40000/(2*60) = 333 (向上取個整350)既每秒要求處理的請求數是350

每秒實際處理請求數量=tps數量 * 1000【tps單位秒，需要切換為毫秒】/tps處理時間

TPS數量 > 每秒要求處理的請求數 * tps返回時間【加入按200ms計算】/1000ms

帶入上面數據計算

tps>(350 * 200)/1000，具體tps>70。

因此可讓壓力測試人員按照tps100來壓接口，返回在200ms以內就滿足性能要求。

當然如果實際tps50的返回時間為100ms，則按照這個粗略的公式來推算，也是能夠支撐的(350 * 100/1000=35，也就是說tps高于35，返回100ms以內也是可以的)

案例2，我們來看一個日常服務的算法

如：一個100w訪問的服務，每天訪問集中白天8小時，每個用戶大約會請求3個接口，每天早上9點是峰值。

首先計算日均請求數(每秒)

按8小時 100w訪問量、平均3個接口請求計算

每秒日均請求數=100w(訪問量)* 3(每個訪問量平均請求接口數)/8(小時)/3600(切換成秒)，結果就是每秒請求100次。

按接口200ms返回，tps需要> 100 * 200/1000，即>20就行了。

如考慮日常服務的峰值，則按4 * 日均，即每秒請求400次，則tps>80即可，因此可推薦按tps=100來做接口的壓力測試。

如果用整日的數據來計算總請求數，需要按照日流量分布來估算一個峰值數據，可考慮使用 峰值=4 * 日均【當然還是要看你具體的訪問量】

網絡上面的總結

沒啥人用的服務 tps 20，返回有300ms就行了

十萬到百萬級的服務，響應能達到tps50 /200ms就可以了

后臺服務，能達到tps 20 / 200ms即可(通常后臺同時使用也沒多少人)

秒殺類的短時間高并發……TPS100或200 在 100ms內響應 應該也能撐一段時間(具體情況還是要看業務量)

在jmeter中，具體的平均響應時間，tps既吞吐量，請求次數都可以在圖表中看到，一般來說在請求沒有錯誤率的情況下，逐步提高請求數，查看平均響應時間，tps既吞吐量，并結合服務器的內存，cpu 使用率不高于80%來獲取系統壓力下的指標情況，從而進一步分析在目前服務器配置情況下，能否滿足

如果這篇文章對你有所啟發，點贊、轉發都是一種支持

總結

以上是生活随笔為你收集整理的性能测试 获取 服务器间响应时间,性能测试指标分析TPS、响应时间、并发量等...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。