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

本文是《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秒時，并發用戶數才會等于每秒請求數；否則，每秒請求數可能大于并發用戶數或小于并發用戶數。