常用的工具
jmeter，loadrunner，locust
併發數
併發數是指在同一個時間點，同時請求服務的客戶數量。
比如大家常說的：『 我的網站可以承受一萬併發。 』在通常情況下指的是：如果同時有一萬名用戶訪問網站，所有人都可以正常獲得服務。而不會有超時或連接拒絕情況發生。
吞吐率
吞吐率指的是服務處理請求的效率，計算方式爲 （ 總處理請求數 / 總耗時 ）。
HTTP 服務的吞吐率通常以 RPS（Requests Per Second 請求數每秒）作爲單位。吞吐量越高，代表服務處理效率就越高。換句話說就是網站的性能越高。
注意：吞吐率和併發數是兩個完全獨立的概念。拿銀行櫃檯來舉個例子，併發數指同時有多少人往銀行櫃檯湧來。吞吐率則指銀行櫃檯在一段時間內可以服務多少個人。
但是在性能測試中，二者之間通常會呈現出一種關聯關係。當併發數增大時，吞吐率通常也會隨之上升（ 多用戶發揮出並行處理優勢） 。但在併發數超過某個邊界值後，吞吐率則會下降 （用戶過多，花在上下文切換的開銷急劇增大，又或者內存消耗過多）。
響應時間
響應時間指的是用戶從發出請求到接收完響應之間的總耗時，它由網絡傳輸耗時、服務處理耗時等多個部分組成。通常以毫秒（ms）作爲單位。
與併發數的關係：一般來說，隨着併發數增大，單個用戶的響應時間通常會隨之增加。這很好理解，餐館喫飯的人越多，單個顧客等待的時間就越長。
與吞吐率的關係：更高的吞吐率通常意味着更低的響應時間。因爲吞吐率是以 單位時間 內的請求處理能力來計算的。
平均響應時間與百分位響應時間
平均響應時間指的是所有請求平均花費的時間，如果有100個請求，其中 98 個耗時爲 1ms，其他兩個爲 100ms。那麼平均響應時間爲 (98 * 1 + 2 * 100) / 100.0 = 2.98ms 。
百分位數（ Percentile - Wikipedia ）是一個統計學名詞。以響應時間爲例， 99% 的百分位響應時間 ，指的是 99% 的請求響應時間，都處在這個值以下。
拿上面的響應時間來說，其整體平均響應時間雖然爲 2.98ms，但 99% 的百分位響應時間卻是 100ms。
相對於平均響應時間來說，百分位響應時間通常更能反映服務的整體效率。現實世界中用的較多的是 98% 的百分位響應時間，比如 GitHub System Status 中就有一條 98TH PERC. WEB RESPONSE TIME 曲線。
平均響應時間： 所有請求的平均響應時間，取的平均值
95%percentile ： 統計學術語，如果將一組數據從小到大排序，並計算相應的累計百分位，則某一百分位所對應數據的值就稱爲這一百分位的百分位數。可表示爲：一組n個觀測值按數值大小排列。如，處於p%位置的值稱第p百分位數。
例如有100個請求， 每個請求的響應時間分別是 1-100 平均分佈
平均響應時間： 1-100 的平均值，即 50.5
95% percentile ： 按從小到大排序，累計第95百分位，也就是 95 （即樣本里95% 的數據都不高於這個值）
影響性能的原因
硬件當然是內存越大越好，CPU同樣也是，寬帶要選擇大流量，CDN加速，二級域名之類的都能優化性能。
前臺要控制同一用戶的某個接口訪問次數，簡單的來說就是防止用戶多次點按鈕去重複訪問造成流量浪費。
從一個服務器角度來說，從線程池裏獲取線程到執行完將線程返回到線程池過程爲一個請求，這裏面有影響的首先就是線程池的大小，核心線程數越大，性能就越好，若實際情況儘量不要超過最大線程數。
JVM和硬件十分相關，需要根據實際情況進行調整，其他連接如redis連接，數據庫連接，同樣都要注意連接池的配置，以及資源釋放問題，之前遇到一些連接釋放失敗的bug導致服務器的性能越來越差。
從架構上來講，後臺的集羣數量，主從配置的模式等等更加影響性能，實際中不同業務對應不同的後臺集羣服務，大多數情況都是根據業務配置不同數量的服務器。
實際背景
做項目開發的時候，不止一次被性能測試問“這個服務性能要求是多少？”他期望能得到一個這次接口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對系統性能進行簡單判斷，以滿足日常性能測試需求。
性能測試的指標是怎麼來的呢？
1、產品和運營要給出業務匡算：
這個服務，在多長時間段，多少人會訪問
2、性能要求上，通常情況下的APP應該如何？
頁面訪問的2、5、8原理（用戶進入服務2s內要展示完所有內容，超過5秒用戶就無法忍受了，超過8秒就沒有人再等了，直接關閉服務）
因此頁面的渲染時間+資源文件的載入時間+接口的獲取時間需要保證1s~2s內完成
3、這個條件下接口獲取時間多長合適？
無腦建議200ms以內（考慮到你頁面也要2s打開，還要給其他工作留時間）
怎麼通過業務量來計算TPS多少合適呢？
直接上公式不太好理解，我們先看案例
案例1，秒殺型算法
案例的業務量要求
某業務，類似秒殺型，用戶估算有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以內也是可以的）
案例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來做接口的壓力測試。
相關總結
時間段越短，數據也越接近於瞬間併發
如果用整日的數據來計算總請求數，需要按照日流量分佈來估算一個峯值數據，日常APP可考慮使用 峯值=4 * 日均【當然還是要看你具體的訪問量】
結論
一般推薦，如果你：
沒啥人用的服務 tps 20，返回有300ms就行了
十萬到百萬級的服務，響應能達到tps50 /200ms就可以了
後臺服務，能達到tps 20 / 200ms即可（通常後臺同時使用也沒多少人）
秒殺類的短時間高併發……TPS100或200（小型網站） 在 100ms內響應 應該也能撐一段時間（具體情況還是要看業務量，大型網站同一時刻許多秒殺活動，小型網站可能只有一個，不考慮分佈式服務情況下）