《LoadRunner 沒有告訴你的》之四——理解性能

版權聲明：本文能夠被轉載，可是在未經本人許可前，不得用於任何商業用途或其餘以盈利爲目的的用途。本人保留對本文的一切權利。如需轉載，請在轉載是保留此版權聲明，並保證本文的完整性。也請轉貼者理解創做的辛勞，尊重做者的勞動成果。

做者：陳雷 (Jackei)

郵箱：jackeichan@gmail.com

Blog：http://jackei.cnblogs.com

 

本文是《LoadRunner沒有告訴你的》系列文章的第四篇，在這篇短文中，我將盡量用簡潔清晰的文字寫下我對「性能」的見解，並澄清幾個容易混淆的概念，幫助你們更好的理解「性能」的含義。

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

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

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

換句話說，「好的性能」意味着更大的最佳併發用戶數（The Optimum Number of Concurrent Users）和 最大併發用戶數（The Maximum Number of Concurrent Users）。有關「最佳/最大併發用戶數」的概念請參見《理髮店模型》一文。 

另外，從系統的視角來看，所須要關注的還包括三個與「性能」有關的屬性：可靠性（Reliability），可伸縮性（Scalability）和 可恢復性（Recoverability）——我將會在本系列文章的第五篇「無處不在的性能測試」中專門討論這三個屬性的含義和相關的實踐經驗。

 

響應時間

 

上面這張圖引自段念兄的一份講義，不過我略做了些修改。從圖中咱們能夠清楚的看到一個請求的響應時間是由幾部分時間組成的，包括

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

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

A1：Web/App Server 對請求進行處理所須要的時間；

A2：DB Server 對請求進行處理所需的時間；

A3：Web/App Server 對 DB Server 返回的結果進行處理所需的時間；

N1：請求由客戶端發出並達到Web/App Server 所須要的時間；

N2：若是須要進行數據庫相關的操做，由Web/App Server 將請求發送至DB Server 所須要的時間；

N3：DB Server 完成處理並將結果返回Web/App Server 所需的時間；

N4：Web/App Server 完成處理並將結果返回給客戶端所需的時間；

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

在理解了響應時間的組成以後，能夠幫助咱們經過對響應時間的分析來更好的識別和定位系統的性能瓶頸。

 

吞吐量 vs. 吞吐量

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

 

併發用戶數 ≠ 每秒請求數

這是兩個容易讓初學者混淆的概念。

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

因此，只有當響應時間剛好是1秒時，併發用戶數纔會等於每秒請求數；不然，每秒請求數可能大於併發用戶數或小於併發用戶數。