MILY: 'Comic Sans MS'; mso-bidi-font-size: 10.5pt">
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秒時，并發用戶數才會等于每秒請求數；否則，每秒請求數可能大于并發用戶數或小于并發用戶數。
