VU TPS QPS RT 計算公式

1.背景

    最近看了阿里巴巴中間件寫的一篇文章，講述了關於併發，RPS，RT之間的關係。感受收穫頗豐。本身使用JMeter工具對公式進行了驗證。

2.驗證

咱們先來看幾個基礎知識定義：

1. TPS：每秒完成的事務數。
2. QPS：每秒發送的請求數（同RPS）。
3. RT:交易響應時間。
4. VU虛擬用戶數（VU是LR中的叫法，對應JMeter裏的線程數）

針對以上術語定義，相信你們早已耳濡目染。惟一須要強調的是TPS（能夠包含1到N個請求），本文均以一個請求來進行測試驗證。

Little定律公式：併發用戶數 = QPS x RT

• 測試腳本結構圖：

   

說明：JMeter版本5.1.1,採用JMeter自帶Java請求（JavaTest），將Sleep_Time設置爲1。

• 線程組設爲100併發，運行10秒中，測試結果以下：

套用公式：併發數=701.3291634089131 x 0.133 = 93.276778679 ,與預期併發數（100）相差較大。初步懷疑是樣本數太少，致使誤差較大。

• 線程組設爲100併發，運行30秒中，測試結果以下：

套用公式：併發數=752.193926548995 x 0.129 = 97.033016524692 ,與預期併發數（100）仍是有點差距。初步驗證懷疑是正確的。

• 線程組設爲100併發，運行180秒中，測試結果以下：

套用公式：併發數=789.7479728492222 x 0.126 = 99.508244579002,與預期併發數（100）基本一致。考慮到性能消耗，能夠認定公式的正確性（假象下若是此場景運行無限長時間，那麼能夠推測出：吞吐量 x 平均響應時間的值無限接近線程組設定的併發值）。

3.QPS與TPS引起的問題

咱們再來驗證個有趣的問題：

由此圖能夠推算出：ART爲126ms,也就是1s能發送大約7.9365個請求，100併發1秒能發出約：793.650個請求，也就是QPS=793.650筆/秒，與圖中吞吐量的值幾乎一致。能夠看做：當前QPS與吞吐量值相等，而此時的吞吐量能夠當作TPS。

咱們改動下腳本：

說明：增長了QPS控制器

咱們再次執行，結果以下：

筆者腳本中限制了：最大QPS爲200，此時吞吐量約爲198.682，二者基本一致，進而驗證了（筆者感受致使偏差的緣由在於：場景啓動時須要一個warm up 過程，不能在啓動場景的瞬間就達到限制的200QPS）。筆者將腳本中的JAVA請求換成本地HTTP請求，測出的現象均一致,因爲篇幅限制就再也不贅述。

     此時再用老套路計算下QPS,平均響應時間爲127ms,推算出1s能發送7.87401筆，100併發能發送787.401筆，我擦了，爲啥與預期200筆差距這麼大？

注意：這種方式計算出的值只是理論值，由於筆者腳本中已經設置了200QPS限制，並不限制請求的RT（換句話說只限制了單位時間內發送的請求量，再或者能夠理解成限流）

結論：單獨對QPS與TPS進行對比是沒有意義的，他們是不一樣的衡量指標。在真實的環境下每每一個事務包含多個請求（即多個請求組成一個事務），此時再比較二者，會發現QPS要比TPS大幾倍。