上面這張圖引自段念兄的一份講義，不過(guò)我略作了些修改。從圖中我們可以清楚的看到一個(gè)請(qǐng)求的響應(yīng)時(shí)間是由幾部分時(shí)間組成的，包括

C1：用戶請(qǐng)求發(fā)出前在客戶端需要完成的預(yù)處理所需要的時(shí)間；

C2：客戶端收到服務(wù)器返回的響應(yīng)后，對(duì)數(shù)據(jù)進(jìn)行處理并呈現(xiàn)所需要的時(shí)間；

A1：Web/App Server 對(duì)請(qǐng)求進(jìn)行處理所需要的時(shí)間；

A2：DB Server 對(duì)請(qǐng)求進(jìn)行處理所需的時(shí)間；

A3：Web/App Server 對(duì) DB Server 返回的結(jié)果進(jìn)行處理所需的時(shí)間；

N1：請(qǐng)求由客戶端發(fā)出并達(dá)到Web/App Server 所需要的時(shí)間；

N2：如果需要進(jìn)行數(shù)據(jù)庫(kù)相關(guān)的操作，由Web/App Server 將請(qǐng)求發(fā)送至DB Server 所需要的時(shí)間；

N3：DB Server 完成處理并將結(jié)果返回Web/App Server 所需的時(shí)間；

N4：Web/App Server 完成處理并將結(jié)果返回給客戶端所需的時(shí)間；

從用戶的角度來(lái)看，響應(yīng)時(shí)間＝(C1+C2)+(A1+A2+A3)+(N1+N2+N3+N4)；但是從系統(tǒng)的角度來(lái)看，響應(yīng)時(shí)間只包括(A1+A2+A3)+(N1+N2+N3+N4)。

在理解了響應(yīng)時(shí)間的組成之后，可以幫助我們通過(guò)對(duì)響應(yīng)時(shí)間的分析來(lái)更好的識(shí)別和定位系統(tǒng)的性能瓶頸。

吞吐量 vs. 吞吐量

在不同的測(cè)試工具中，對(duì)于吞吐量(Throughput)會(huì)有不同的解釋。例如，在LoadRunner中，這個(gè)指標(biāo)是以字節(jié)數(shù)為單位來(lái)衡量網(wǎng)絡(luò)吞吐量的，而在JMeter中則是以事務(wù)數(shù)/秒為單位來(lái)衡量系統(tǒng)的響應(yīng)能力的。不過(guò)在大多數(shù)英文的性能測(cè)試方面的書(shū)籍或資料中，吞吐量的定義使用的是后者。

并發(fā)用戶數(shù) ≠ 每秒請(qǐng)求數(shù)

這是兩個(gè)容易讓初學(xué)者混淆的概念。

簡(jiǎn)單說(shuō)，當(dāng)你在性能測(cè)試工具或者腳本中設(shè)置了100并發(fā)用戶數(shù)后，并不能期望著一定會(huì)有每秒100個(gè)請(qǐng)求發(fā)給服務(wù)器。事實(shí)上，對(duì)于一個(gè)虛擬用戶來(lái)說(shuō)，每秒發(fā)出多少請(qǐng)求只跟服務(wù)器返回響應(yīng)的速度有關(guān)。如果虛擬用戶在0.5秒內(nèi)就收到了響應(yīng)，那么它會(huì)立即發(fā)出第二個(gè)請(qǐng)求；而如果要一直等待3秒才能得到響應(yīng)，它將會(huì)一直等到收到響應(yīng)后才發(fā)出第二個(gè)請(qǐng)求。也就是說(shuō)，并發(fā)用戶數(shù)的設(shè)置只是保證服務(wù)器在任一時(shí)刻都有100個(gè)請(qǐng)求需要處理，而并不一定是保證每秒中發(fā)送100個(gè)請(qǐng)求給服務(wù)器。

所以，只有當(dāng)響應(yīng)時(shí)間恰好是1秒時(shí)，并發(fā)用戶數(shù)才會(huì)等于每秒請(qǐng)求數(shù)；否則，每秒請(qǐng)求數(shù)可能大于并發(fā)用戶數(shù)或小于并發(fā)用戶數(shù)。