1 壓力測試中的指標
1.1 TPS
TPS 即Transactions Per Second的縮寫，每秒處理的事務數目。一個事務是指一個客戶機向服務器發送請求然后服務器做出反應的過程**(完整處理，即客戶端發起請求到得到響應)**。客戶機在發送請求時開始計時，收到服務器響應后結束計時，以此來計算使用的時間和完成的事務個數，最終利用這些信息作出的評估分。一個事務可能對應多個請求，可以參考下數據庫的事務操作。
1.2 QPS
QPS 即Queries Per Second的縮寫，每秒能處理查詢數目(完整處理，即客戶端發起請求到得到響應)。是一臺服務器每秒能夠相應的查詢次數，是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標準。
我們從它的英文全名可以得出它是查詢意思，原來在因特網上，作為域名系統服務器的機器的性能經常用每秒查詢率來衡量。對應fetches/sec，即每秒的響應請求數。 雖然名義上是查詢的意思，但實際上，現在習慣于對單一接口服務的處理能力用QPS進行表述（即使它并不是查詢操作）。
1.3 平均處理時間（RT）
RT：響應時間，處理一次請求所需要的平均處理時間。
我們一般還會關注90%請求的的平均處理時間，因為可能因網絡情況出現極端情況。
1.4 并發用戶數(并發量)
每秒對待測試接口發起請求的用戶數量。
1.5 換算關系
QPS = 并發數/平均響應時間
并發量 = QPS * 平均響應時間
比如3000個用戶(并發量)同時訪問待測試接口，在用戶端統計，3000個用戶平均得到響應的時間為1188.538ms。所以QPS=3000/1.188538s= 2524.11 q/s。
我們就可以這樣描述本次測試，在3000個并發量的情況下，QPS為2524.11，平均響應事件為1188.538ms
1.6 TPS和QPS的區別
這個問題開始，我認為這兩者應該是同一個東西,但在知乎上看到他們的英文名，現在我認為：
QPS 每秒能處理查詢數目，但現在一般也用于單服務接口每秒能處理請求數。
TPS 每秒處理的事務數目，如果完成該事務僅為單個服務接口，我們也可以認為它就是QPS。
PS:還有一個RPS的的概念 request per second 。每秒請求數，在一定條件下和QPS 和TPS類似。
2 壓力測試方法
我們可以使用壓測工具模擬多用戶對系統進行壓力測試。后面會有壓測工具的介紹
而測試的方式是，以一定請求總量，保持不變，逐步增加并發量，觀察QPS的變化及平均響應時間的變化。
比如10000的總請求數，然后測試100的并發量情況下的QPS值，然后200, 300, 400, 500等。
一個系統吞吐量通常由TPS、并發數兩個因素決定，每套系統這兩個值都有一個相對極限值，在應用場景訪問壓力下，只要某一項達 到系統最高值，系統的吞吐量就上不去了，如果壓力繼續增大，系統的吞吐量反而會下降，原因是系統超負荷工作，上下文切換、內存等等其它消耗導致系統性能下降。這里給出一份使用ab工具的壓測圖。
從圖中可以看出2000的并發量時，QPS已經達到2500左右，后續加大并發數仍維持在2500，說明該接口在該配置下，QPS為2500，即每秒該系統的能力只能處理2500個請求左右，后面加大的并發量，只會導致平均響應時間的增加。（PS:因為每秒只能處理2500個請求，而一次性有7000的并發，自然會造成請求堆積，導致平均響應時間會變長）我們看到超過14000之后連QPS也開始急劇下降，說明系統超負荷工作，導致性能開始急劇下降。而一般情況下，我們認為平均響應時間達到一定值，就已經不可以接受了。
3 相關文檔
估計物聯網設備并發量整理的blog：
http://www.zmynmublwnt.cn/article/220296.html
壓力測試工具ab工具：
http://www.zmynmublwnt.cn/article/220607.html
Apache下分析ab性能測試結果：
http://www.zmynmublwnt.cn/article/220606.html
到此這篇關于服務器壓力測試概念及方法(TPS/并發量)的文章就介紹到這了。希望對大家的學習有所幫助，也希望大家多多支持服務器之家。
原文鏈接：https://blog.csdn.net/m0_37263637/article/details/88749318
