1.背景
最近看了阿里巴巴中間件寫的一篇文章，講述了關於並發，RPS，RT之間的關系。感覺收獲頗豐。自己使用JMeter工具對公式進行了驗證。
2.驗證
我們先來看幾個基礎知識定義：
- TPS：每秒完成的事務數。
- QPS：每秒發送的請求數（同RPS）。
- RT:交易響應時間。
- 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大幾倍。