性能測試中容易混淆的概念

一、併發用戶數≠每秒請求數

      簡單說，當你在性能測試工具或者腳本中設置了100併發用戶數後，並不能指望着必定會有每秒100個請求發給服務器。事實上，對於一個虛擬用戶來講，每秒發出多少請求只跟服務器返回響應的速度有關，若是虛擬用戶在0.5秒內就收到了響應，那麼它會當即發出第二個請求；而若是要一直等待3秒才能獲得響應，它將會一直等到收到響應後才發出第二個請求。例如，若是用戶發出請求後，0.2s內獲得響應，那麼100個用戶每秒完成500個請求；只有當響應時間剛好是1秒時，併發用戶數纔會等於每秒請求數.

     也就是說，併發用戶數的設置只是保證服務器在任一時刻都有100個請求須要處理，而並不必定是保證每秒中發送100個請求給服務器。

二、thought與tps

     在不一樣的測試工具中，對於吞吐量(Throughput)會有不一樣的解釋。例如，在LoadRunner中，這個指標是以字節數爲單位來衡量網絡吞吐量的，而在JMeter中則是以事務數/秒爲單位來衡量系統的響應能力的。不過在大多數英文的性能測試方面的書籍或資料中，吞吐量的定義使用的是後者。

三、響應時間

C1：用戶請求發出前在客戶端須要完成的預處理所須要的時間；

 

C2：客戶端收到服務器返回的響應後，對數據進行處理並呈現所須要的時間；

從用戶的角度來看，響應時間＝(C1+C2)+(A1+A2+A3)+(N1+N2+N3+N4)；可是從系統的角度來看，響應時間只包括(A1+A2+A3)+(N1+N2+N3+N4)。

四、如何評價性能的優劣:用戶視角vs.系統視角

 

對於最終用戶(End-User)來講，評價系統的性能好壞只有一個字——「快」。最終用戶並不須要關心繫統當前的狀態——即便系統這時正在處理着成千上萬的請求，對於用戶來講，由他所發出的這個請求是他惟一須要關心的，系統對用戶請求的響應速度決定了用戶對系統性能的評價。

 

而對於系統的運營商和開發商來講，指望的是可以讓儘量多的用戶在任意時刻都擁有最好的體驗，這就要確保系統可以在同一時間內處理更多的用戶請求。正如在《理髮店模型》一文中所描述的：系統的負載（併發用戶數）與吞吐量（每秒事務數）、響應時間以及資源利用率（包括軟硬件資源）之間存在着一個「此消彼長」的關係。所以，從系統的運營商和開發商的角度來看，所謂的「性能」是一個總體的概念，是系統的負載與吞吐量、可接受的響應時間以及資源利用率之間的平衡。

 

換句話說，「好的性能」意味着更大的最佳併發用戶數（The Optimum Number of Concurrent Users）和最大併發用戶數（The Maximum Number of Concurrent Users）。

 

五、最佳用戶數與最大用戶數

、

    圖中有三條曲線，分別表示資源的利用狀況（Utilization，包括硬件資源和軟件資源）、吞吐量（Throughput，這裏是指每秒事務數）以及響應時間（Response Time）。圖中座標軸的橫軸從左到右表現了併發用戶數（Number of Concurrent Users）的不斷增加。

最佳用戶數：吞吐量和資源佔用率響應增加，可是用戶響應時間變化不大

最大用戶數：資源佔用達到飽和，吞吐量增加明顯放緩甚至中止增加，而響應時間卻進一步延長

舉例，假如一個系統的最佳併發用戶數是50，那麼一旦併發量超過這個值，系統的吞吐量和響應時間必然會 「此消彼長」；若是系統負載長期大於這個數，必然會致使用戶的滿意度下降並最終達到一種沒法忍受的地步。因此咱們應該 保證最佳併發用戶數要大於系統的平均負載。要補充的一點是，當咱們須要對一個系統長時間施加壓力——例如連續加壓3-5天，來驗證系統的可靠性或者說穩定性時，咱們所使用的併發用戶數應該等於或小於「最佳併發用戶數」

對於一個系統來講，咱們應該 確保系統的最大併發用戶數要大於系統須要承受的峯值負載。