先說結(jié)論
一般推薦吴攒，如果你：
沒啥人用的服務(wù) tps 20，返回有300ms就行了
十萬到百萬級的服務(wù)砂蔽，響應(yīng)能達(dá)到tps50 /200ms就可以了
后臺服務(wù)洼怔，能達(dá)到tps 20 / 200ms即可（通常后臺同時使用也沒多少人）
秒殺類的短時間高并發(fā)……TPS100或200 在 100ms內(nèi)響應(yīng) 應(yīng)該也能撐一段時間（具體情況還是要看業(yè)務(wù)量）
背景
做項目開發(fā)的時候，不止一次被性能測試問“這個服務(wù)性能要求是多少左驾？”他期望能得到一個這次接口TPS壓到50還是100镣隶，返回時間是100ms還是200ms的回答。然后壓力測試的腳本就跑起來诡右，挨個接口就去壓了安岂。
但作為產(chǎn)品我怎么知道報多少合適呢？（是的帆吻，在某些團(tuán)隊這是研發(fā)負(fù)責(zé)人應(yīng)該考慮的）域那。通常我們是只知道業(yè)務(wù)量，怎么轉(zhuǎn)換成tps猜煮、返回時間的要求呢次员？（有時候業(yè)務(wù)量都估算不出來，那這種場景下你就按最頂部的推薦的來測吧王带。）
現(xiàn)在淑蔚，只要10分鐘，讓你了解怎么計算這些內(nèi)容愕撰。
首先刹衫，需要知道不同的產(chǎn)品有不同的應(yīng)對要求
手機(jī)發(fā)貨的搶購秒殺場景和美團(tuán)的場景需求不一致，導(dǎo)致產(chǎn)品性能要求就不一致
千萬級用戶的app和十萬級app盟戏，同樣的性能要求绪妹，轉(zhuǎn)換為技術(shù)指標(biāo)上也不一致
繼續(xù)計算甥桂，我們需要了解
什么是TPS
Transactions Per Second（每秒傳輸?shù)氖挛锾幚韨€數(shù)柿究，或者說每秒系統(tǒng)接收的任務(wù)數(shù)量），系統(tǒng)接收到任務(wù)后會有一個處理時間黄选。
在壓力測試時蝇摸，測試人員會主動按一定tps的量來主動發(fā)起接口請求婶肩，比如tps=50，就是每秒請求50次貌夕，獲取一個平均的響應(yīng)時間（單位一般都是毫秒ms）律歼。壓力測試人員口中的TPS50 200ms返回，就是指每秒測試人員主動發(fā)起50次請求啡专，這些請求會在平均200ms返回险毁。
由于其他技術(shù)指標(biāo)如QPS（數(shù)據(jù)的每秒查詢個數(shù)）等性能都會在tps這個維度上展示出來，因此可通過tps對系統(tǒng)性能進(jìn)行簡單判斷们童，以滿足日常性能測試需求畔况。
性能測試的指標(biāo)是怎么來的呢？
1慧库、產(chǎn)品和運營要給出業(yè)務(wù)匡算：
這個服務(wù)跷跪，在多長時間段，多少人會訪問
2齐板、性能要求上吵瞻，通常情況下的APP應(yīng)該如何？
頁面訪問的2甘磨、5橡羞、8原理（用戶進(jìn)入服務(wù)2s內(nèi)要展示完所有內(nèi)容，超過5秒用戶就無法忍受了济舆，超過8秒就沒有人再等了尉姨，直接關(guān)閉服務(wù)）
因此頁面的渲染時間+資源文件的載入時間+接口的獲取時間需要保證1s~2s內(nèi)完成
3、這個條件下接口獲取時間多長合適吗冤？
無腦建議200ms以內(nèi)（考慮到你頁面也要2s打開又厉，還要給其他工作留時間）
怎么通過業(yè)務(wù)量來計算TPS多少合適呢？
直接上公式不太好理解椎瘟，我們先看案例
案例1覆致，秒殺型算法
案例的業(yè)務(wù)量要求
某業(yè)務(wù)，類似秒殺型肺蔚，用戶估算有2W左右煌妈，每個用戶平均請求2次接口（查詢用戶信息接口、查詢業(yè)務(wù)接口）宣羊， 這些用戶大概率會在2分鐘內(nèi)會訪問我們的系統(tǒng)璧诵，業(yè)務(wù)要保證用戶2s能打開頁面
TPS的分析
TPS是系統(tǒng)每秒鐘處理的任務(wù)數(shù)量，給定二業(yè)務(wù)場景仇冯，我們就需要先計算出來每秒需要系統(tǒng)處理多少任務(wù)之宿，從而反推在壓力測試的時候，需要給多大的TPS了苛坚。
首先比被，整個系統(tǒng)的總請求數(shù)=用戶（2W）* 每個用戶請求數(shù)（2次）= 40000次
其次色难，每秒要求處理的請求數(shù)=總請求數(shù)/時間（切換到秒） 即約350（333向上取個整吧）。
最后等缀，TPS并發(fā)數(shù)量與每個請求所消耗的時間枷莉，可實際計算出每秒實際能夠處理的請求數(shù)。
即每秒實際處理請求數(shù)量=tps數(shù)量 * 1000【1秒尺迂，需要切換為毫秒】/單組tps處理時間【這里是按200ms返回】
因此笤妙，我們只要保證 每秒實際處理請求數(shù)>每秒要求處理的請求數(shù) 就可以了。
最終結(jié)果就是
TPS數(shù)量 > 每秒要求處理的請求數(shù) * tps返回時間【按200ms計算】/1000ms
帶入數(shù)據(jù)計算
tps>(350 * 200)/1000噪裕，具體tps>70危喉。
因此可讓壓力測試人員按照tps100來壓接口，返回在200ms以內(nèi)就滿足性能要求州疾。
當(dāng)然如果實際tps50的返回時間為100ms辜限，則按照這個粗略的公式來推算，也是能夠支撐的（350 * 100/1000=35严蓖，也就是說tps高于35薄嫡，返回100ms以內(nèi)也是可以的）
案例2，我們來看一個日常服務(wù)的算法
如：一個100w訪問的服務(wù)颗胡，每天訪問集中白天8小時毫深，每個用戶大約會請求3個接口，每天早上9點是峰值毒姨。
首先計算日均請求數(shù)（每秒）
按8小時 100w訪問量哑蔫、平均3個接口請求計算
每秒日均請求數(shù)=100w（訪問量）* 3（每個訪問量平均請求接口數(shù)）/8（小時）/3600（切換成秒），結(jié)果就是每秒請求100次弧呐。
按接口200ms返回闸迷，tps需要> 100 * 200/1000，即>20就行了俘枫。
如考慮日常服務(wù)的峰值腥沽，則按4 * 日均，即每秒請求400次鸠蚪，則tps>80即可今阳，因此可推薦按tps=100來做接口的壓力測試。
相關(guān)總結(jié)
時間段越短茅信，數(shù)據(jù)也越接近于瞬間并發(fā)
如果用整日的數(shù)據(jù)來計算總請求數(shù)盾舌，需要按照日流量分布來估算一個峰值數(shù)據(jù)，日常APP可考慮使用 峰值=4 * 日均【當(dāng)然還是要看你具體的訪問量】
如果覺得以上繁雜蘸鲸，反正你也可以參考這個結(jié)論：
沒啥人用的服務(wù) tps 20妖谴，返回有300ms就行了
十萬到百萬級的服務(wù)，響應(yīng)能達(dá)到tps50 /200ms就可以了
后臺服務(wù)棚贾，能達(dá)到tps 20 / 200ms即可（通常后臺同時使用也沒多少人）
秒殺類的短時間高并發(fā)……TPS100或200 在 100ms內(nèi)響應(yīng) 應(yīng)該也能撐一段時間（具體情況還是要看業(yè)務(wù)量）
————————————————
版權(quán)聲明：本文為CSDN博主「空城雀」的原創(chuàng)文章窖维，遵循CC 4.0 BY-SA版權(quán)協(xié)議，轉(zhuǎn)載請附上原文出處鏈接及本聲明妙痹。
原文鏈接：https://blog.csdn.net/weixin_43639512/article/details/100118274
