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

圖2：截取自Avalanche Commander Result——Client Real Time報告

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

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

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

圖3：截取自Avalanche Commander Result——Client Real Time報告

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

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

圖6：Avalanche抓包文件，對應圖5 Server Transactions的配置

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

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

一般來說只有當1條TCP連接只傳輸一個事務時，CPS才會等于TPS，如果啟用HTTP長連接功能，1條TCP連接傳輸多個事務，TPS就會是CPS的多倍關系。如下圖所示，我們配置1條TCP連接傳輸4個HTTP事務，最終結果CPS和TPS就是1比4的關系。

圖7：截取自Avalanche Commander Result——Client Real Time報告

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

圖8：截取自Avalanche Commander Result——Client Real Time報告

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

在四七層測試中，除了要關注二層吞吐量。還需要關注應用層吞吐量。

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

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

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

圖9：截取自Avalanche Commander Result——Client Real Time報告

5、Response Time 響應時間

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

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

圖10：截取自Avalanche Commander Result——Client Summary報告

Page Response Time（頁面響應時間）：

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

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

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

這意味著較高的頁面數(shù)可能仍然會導致較短的平均頁面響應時間

圖11：截取自Avalanche Commander Result——Client Summary報告

圖12：截取自Avalanche Commander Result——Client Summary報告

URL Response Time（URL響應時間）：

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

對于沒有設置Keep-Alive的HTTP 1.0，當從服務器接收到FIN時，將認為檢索到了URL。

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

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

注意:即使您在Action列表中只有一個URL，頁面響應時間也可能低于URL響應時間，特別是當您有重定向和不成功的交易時。

如果您只有一個URL并且交易100%成功，那么頁面響應時間和URL響應時間應該匹配。

Time To TCP SYN/ACK：

從會話發(fā)出SYN報文到收到相應的ACK報文所花費的時間，單位為毫秒。

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

Time To First Data Byte：

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

Estimated Server Response Time (ms) ：

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

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

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

RTT：

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

圖13：截取自Avalanche Commander Result——Client Summary報告