服務器壓力測試概念及方法(TPS/並發量)

Posted on by

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：

https://www.jb51.net/article/231516.htm

壓力測試工具ab工具：

https://www.jb51.net/article/231502.htm

Node express框架壓測結果：

https://www.jb51.net/article/231512.htm

到此這篇關於服務器壓力測試概念及方法(TPS/並發量)的文章就介紹到這瞭。希望對大傢的學習有所幫助，也希望大傢多多支持WalkonNet。

推薦閱讀：