在儀表的統(tǒng)計(jì)中Current Established TCP Connections就代表了并發(fā)連接數(shù)的指標(biāo)。

圖2：截取自Avalanche Commander Result——Client Real Time報(bào)告

在日常測(cè)試中，有時(shí)候我們會(huì)提到四層并發(fā)或者七層并發(fā)的概念，那么什么是四層并發(fā)，什么是七層并發(fā)呢？

以Avalanche儀表為例，如果我們使用Think方式來控制TCP的連接時(shí)長，Avalanche模擬的用戶會(huì)在完成HTTP請(qǐng)求后等待Think時(shí)間（模擬用戶瀏覽網(wǎng)頁）計(jì)時(shí)完成后再關(guān)閉連接。

由于此時(shí)HTTP交互已經(jīng)完成，只是TCP的連接在保持，因此這種方式我們稱之為四層并發(fā)。

圖3：截取自Avalanche Commander Result——Client Real Time報(bào)告

如果我們不使用Think參數(shù)來保持連接，而是在服務(wù)器側(cè)通過服務(wù)器延遲響應(yīng)的方式來控制連接的時(shí)長，Avalanche模擬的服務(wù)器會(huì)在收到HTTP請(qǐng)求后等待Lantency的時(shí)間計(jì)時(shí)完成再回復(fù)響應(yīng)數(shù)據(jù)，由于此時(shí)HTTP的會(huì)話也處于保持階段，因此采用這種方式來控制連接時(shí)長的方法我們稱之為七層并發(fā)。

圖5：截取自Avalanche Commander Server Transactions頁面

圖6：Avalanche抓包文件，對(duì)應(yīng)圖5 Server Transactions的配置

3、TPS(Transactions/Second) 每秒事務(wù)數(shù)

TPS(Transactions/Second)每秒會(huì)話數(shù)一般指每秒鐘HTTP事務(wù)成功的交互次數(shù)。對(duì)于服務(wù)器來說，如果TPS能力突出，則意味著服務(wù)器多線程處理能力優(yōu)秀，反之，如果服務(wù)器的多線程處理能力不強(qiáng)，或者多線程處理效率較低，HTTP事務(wù)交互速率增加后可能會(huì)導(dǎo)致服務(wù)器負(fù)載過高，影響服務(wù)器的響應(yīng)速度和服務(wù)質(zhì)量。每秒會(huì)話數(shù)的處理能力直接關(guān)系到了并發(fā)連接數(shù)以及系統(tǒng)的吞吐量指標(biāo)。每秒會(huì)話數(shù)的處理能力越強(qiáng)，并發(fā)連接數(shù)會(huì)越低，系統(tǒng)的吞吐量就會(huì)越大。

一般來說只有當(dāng)1條TCP連接只傳輸一個(gè)事務(wù)時(shí)，CPS才會(huì)等于TPS，如果啟用HTTP長連接功能，1條TCP連接傳輸多個(gè)事務(wù)，TPS就會(huì)是CPS的多倍關(guān)系。如下圖所示，我們配置1條TCP連接傳輸4個(gè)HTTP事務(wù)，最終結(jié)果CPS和TPS就是1比4的關(guān)系。

圖7：截取自Avalanche Commander Result——Client Real Time報(bào)告

4、Throughput 吞吐量
吞吐量一般指單位時(shí)間內(nèi)成功地傳送數(shù)據(jù)的數(shù)量（以比特、字節(jié)、分組等測(cè)量）。一個(gè)系統(tǒng)的吞度量（承壓能力）與請(qǐng)求對(duì)CPU的消耗、外部接口、IO等等緊密關(guān)聯(lián)。單個(gè)請(qǐng)求對(duì)CPU消耗越高，外部系統(tǒng)接口、IO響應(yīng)速度越慢，系統(tǒng)吞吐能力越低，反之越高。

圖8：截取自Avalanche Commander Result——Client Real Time報(bào)告

系統(tǒng)吞吐量幾個(gè)重要參數(shù)：TPS、并發(fā)數(shù)、響應(yīng)時(shí)間；

在四七層測(cè)試中，除了要關(guān)注二層吞吐量。還需要關(guān)注應(yīng)用層吞吐量。

所謂的應(yīng)用層吞吐量Goodput(或Good throughput)，一般被定義為每單位時(shí)間內(nèi)正確轉(zhuǎn)發(fā)到被測(cè)設(shè)備或系統(tǒng)(DUT/SUT)目的接口的應(yīng)用數(shù)據(jù)比特?cái)?shù)，減去丟失或重傳的比特?cái)?shù)(RFC 2647)。這基本上是應(yīng)用程序協(xié)議所看到的應(yīng)用程序級(jí)吞吐量，不包括重傳的任何TCP數(shù)據(jù)包。TCP/IP報(bào)頭也不包括在內(nèi)。

相對(duì)于傳統(tǒng)網(wǎng)絡(luò)設(shè)備來說，應(yīng)用層網(wǎng)絡(luò)設(shè)備不再簡(jiǎn)單的關(guān)注數(shù)據(jù)報(bào)文的轉(zhuǎn)發(fā)，而更關(guān)注和應(yīng)用協(xié)議相關(guān)的內(nèi)容，如url解析，協(xié)議解析、應(yīng)用特征識(shí)別、應(yīng)用威脅識(shí)別等，并基于此開發(fā)相關(guān)的功能特性。針對(duì)這些特性，通常應(yīng)用層網(wǎng)絡(luò)設(shè)備都有各種各樣的識(shí)別引擎，無論是哪一種算法，其核心的基本要求都需要把數(shù)據(jù)包解封裝到OSI模型的應(yīng)用層。而網(wǎng)絡(luò)層設(shè)備以數(shù)據(jù)包轉(zhuǎn)發(fā)為主要目的，只關(guān)心數(shù)據(jù)包轉(zhuǎn)發(fā)能力，只需要解封到網(wǎng)絡(luò)層，找到對(duì)應(yīng)的路徑信息即可。

數(shù)據(jù)包封裝和解封的層次越多，CPU計(jì)算的負(fù)載就會(huì)越高，最終會(huì)直接體現(xiàn)在性能的衰減上。同樣處理能力的CPU，處理網(wǎng)絡(luò)層數(shù)據(jù)轉(zhuǎn)發(fā)和應(yīng)用層識(shí)別，所呈現(xiàn)的性能特性可能會(huì)截然不同，因此使用傳統(tǒng)網(wǎng)絡(luò)層性能指標(biāo)來評(píng)價(jià)應(yīng)用層設(shè)備的性能，實(shí)際上是有悖于真實(shí)的應(yīng)用場(chǎng)景與測(cè)試需求的。

圖9：截取自Avalanche Commander Result——Client Real Time報(bào)告

5、Response Time 響應(yīng)時(shí)間

響應(yīng)時(shí)間——從字面的意義上來說是指從用戶發(fā)出請(qǐng)求到他們收到響應(yīng)所花費(fèi)的總時(shí)間。越短的響應(yīng)時(shí)間意味著更高的性能和更優(yōu)質(zhì)的用戶體驗(yàn)。然而總的響應(yīng)時(shí)間往往是由很多的子系統(tǒng)的響應(yīng)時(shí)間所構(gòu)成的，如光模塊的光電轉(zhuǎn)換時(shí)間、數(shù)據(jù)在線纜上傳輸?shù)臅r(shí)間、通訊設(shè)備處理的時(shí)間、應(yīng)用程序處理數(shù)據(jù)的時(shí)間等，如何根據(jù)各個(gè)系統(tǒng)的子響應(yīng)時(shí)間來排查優(yōu)化子系統(tǒng)對(duì)于提升整體網(wǎng)絡(luò)性能是非常有意義的。

下面我們將為大家展開談一談Response Time的分類與解讀

圖10：截取自Avalanche Commander Result——Client Summary報(bào)告

Page Response Time（頁面響應(yīng)時(shí)間）：

等于從對(duì)index.html的第一個(gè)GET請(qǐng)求到接收到3.jpg的最后一個(gè)數(shù)據(jù)包所經(jīng)過的總時(shí)間。

最小和最大頁面響應(yīng)時(shí)間是發(fā)送的所有頁面的最小和最大響應(yīng)時(shí)間。

平均頁面響應(yīng)時(shí)間是總頁面響應(yīng)時(shí)間除以總頁面數(shù)。

這意味著較高的頁面數(shù)可能仍然會(huì)導(dǎo)致較短的平均頁面響應(yīng)時(shí)間

圖11：截取自Avalanche Commander Result——Client Summary報(bào)告

圖12：截取自Avalanche Commander Result——Client Summary報(bào)告

URL Response Time（URL響應(yīng)時(shí)間）：

從初始HTTP請(qǐng)求(例如，GET)到被請(qǐng)求的URL被完全檢索的時(shí)間量（收到響應(yīng)最后一個(gè)字節(jié)數(shù)據(jù)），以毫秒為單位，即TTLB(Time To Last Byte)。

對(duì)于沒有設(shè)置Keep-Alive的HTTP 1.0，當(dāng)從服務(wù)器接收到FIN時(shí)，將認(rèn)為檢索到了URL。

對(duì)于HTTP 1.1，當(dāng)接收到響應(yīng)頭中聲明的Content-Length總數(shù)的數(shù)據(jù)包時(shí)，將完全檢索URL。

對(duì)于HTTP 1.1中的分塊（CHUNK）傳輸，當(dāng)服務(wù)器發(fā)送完<CR><LF>0<CR><LF>時(shí)，數(shù)據(jù)被完全接收。

注意:即使您在Action列表中只有一個(gè)URL，頁面響應(yīng)時(shí)間也可能低于URL響應(yīng)時(shí)間，特別是當(dāng)您有重定向和不成功的交易時(shí)。

如果您只有一個(gè)URL并且交易100%成功，那么頁面響應(yīng)時(shí)間和URL響應(yīng)時(shí)間應(yīng)該匹配。

Time To TCP SYN/ACK：

從會(huì)話發(fā)出SYN報(bào)文到收到相應(yīng)的ACK報(bào)文所花費(fèi)的時(shí)間，單位為毫秒。

注意:如果下一跳MAC地址尚未被解析，該值可能包括解析下一跳MAC地址所花費(fèi)的時(shí)間。

Time To First Data Byte：

初始HTTP請(qǐng)求(例如GET)和從服務(wù)器接收到第一個(gè)數(shù)據(jù)包之間的時(shí)間間隔，以毫秒為單位。

Estimated Server Response Time (ms) ：

估算的服務(wù)器響應(yīng)請(qǐng)求所需的時(shí)間(以毫秒為單位)，從服務(wù)器收到HTTP請(qǐng)求的最后一個(gè)字節(jié)到服務(wù)器HTTP響應(yīng)的第一個(gè)字節(jié)的時(shí)間間隔。該統(tǒng)計(jì)數(shù)據(jù)由以下公式得出:

Estimated Server Response Time (ms) =Time To First Data Byte減去兩倍的Time To TCP SYN/ACK

注意:這是對(duì)服務(wù)器響應(yīng)請(qǐng)求所需時(shí)間的估計(jì)。該公式旨在將網(wǎng)絡(luò)損耗時(shí)間從等式中刪除，以便生成僅包含服務(wù)器處理時(shí)間的時(shí)間。損耗時(shí)間是Time To SYN/ACK時(shí)間的兩倍。當(dāng)服務(wù)器響應(yīng)第一個(gè)SYN請(qǐng)求的時(shí)間較短時(shí)，此公式最有效。

RTT：

從發(fā)送數(shù)據(jù)到接收該數(shù)據(jù)的ACK的時(shí)間量，以毫秒為單位。

圖13：截取自Avalanche Commander Result——Client Summary報(bào)告