并發量越大tps越大嗎?一般推薦，如果你：做項目開發的時候，不止一次被性能測試問“這個服務性能要求是多少？”他期望能得到一個這次接口TPS壓到50還是100，返回時間是100ms還是200ms的回答然後壓力測試的腳本就跑起來，挨個接口就去壓了，接下來我們就來聊聊關于并發量越大tps越大嗎?以下内容大家不妨參考一二希望能幫到您!

并發量越大tps越大嗎

一般推薦，如果你：

• 沒啥人用的服務 tps 20，返回有300ms就行了
• 十萬到百萬級的服務，響應能達到tps50 /200ms就可以了
• 後台服務，能達到tps 20 / 200ms即可（通常後台同時使用也沒多少人）
• 秒殺類的短時間高并發……TPS100或200 在 100ms内響應 應該也能撐一段時間（具體情況還是要看業務量）

做項目開發的時候，不止一次被性能測試問“這個服務性能要求是多少？”他期望能得到一個這次接口TPS壓到50還是100，返回時間是100ms還是200ms的回答。然後壓力測試的腳本就跑起來，挨個接口就去壓了。

但作為産品我怎麼知道報多少合适呢？（是的，在某些團隊這是研發負責人應該考慮的）。通常我們是隻知道業務量，怎麼轉換成tps、返回時間的要求呢？（有時候業務量都估算不出來，那這種場景下你就按最頂部的推薦的來測吧。）

現在，隻要10分鐘，讓你了解怎麼計算這些内容。

手機發貨的搶購秒殺場景和美團的場景需求不一緻，導緻産品性能要求就不一緻千萬級用戶的app和十萬級app，同樣的性能要求，轉換為技術指标上也不一緻

什麼是TPS

Transactions Per Second（每秒傳輸的事物處理個數，或者說每秒系統接收的任務數量），系統接收到任務後會有一個處理時間。

在壓力測試時，測試人員會主動按一定tps的量來主動發起接口請求，比如tps=50，就是每秒請求50次，獲取一個平均的響應時間（單位一般都是毫秒ms）。壓力測試人員口中的TPS50 200ms返回，就是指每秒測試人員主動發起50次請求，這些請求會在平均200ms返回。

由于其他技術指标如QPS（數據的每秒查詢個數）等性能都會在tps這個維度上展示出來，因此可通過tps對系統性能進行簡單判斷，以滿足日常性能測試需求。

性能測試的指标是怎麼來的呢？

産品和運營要給出業務匡算：

這個服務，在多長時間段，多少人會訪問 性能要求上，通常情況下的APP應該如何？

頁面訪問的2、5、8原理（用戶進入服務2s内要展示完所有内容，超過5秒用戶就無法忍受了，超過8秒就沒有人再等了，直接關閉服務）

因此頁面的渲染時間 資源文件的載入時間 接口的獲取時間需要保證1s~2s内完成這個條件下接口獲取時間多長合适？

無腦建議200ms以内（考慮到你頁面也要2s打開，還要給其他工作留時間）

怎麼通過業務量來計算TPS多少合适呢？

直接上公式不太好理解，我們先看案例

案例的業務量要求

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

TPS的分析

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

首先，整個系統的總請求數=用戶（2W）* 每個用戶請求數（2次）= 40000次其次，每秒要求處理的請求數=總請求數/時間（切換到秒） 即約350（333向上取個整吧）。最後，TPS并發數量與每個請求所消耗的時間，可實際計算出每秒實際能夠處理的請求數。

即每秒實際處理請求數量=tps數量 * 1000【1秒，需要切換為毫秒】/單組tps處理時間【這裡是按200ms返回】因此，我們隻要保證 每秒實際處理請求數>每秒要求處理的請求數 就可以了。

最終結果就是

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

帶入數據計算

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

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

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

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

首先計算日均請求數（每秒）

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

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

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

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

時間段越短，數據也越接近于瞬間并發如果用整日的數據來計算總請求數，需要按照日流量分布來估算一個峰值數據，日常APP可考慮使用 峰值=4 * 日均【當然還是要看你具體的訪問量】

如果覺得以上繁雜，反正你也可以參考這個結論：

沒啥人用的服務 tps 20，返回有300ms就行了十萬到百萬級的服務，響應能達到tps50 /200ms就可以了後台服務，能達到tps 20 / 200ms即可（通常後台同時使用也沒多少人）秒殺類的短時間高并發……TPS100或200 在 100ms内響應 應該也能撐一段時間（具體情況還是要看業務量）

最後，如需繼續讨論，請留言哈。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!