Web應用系統(tǒng)并發(fā)性能測量的研究與應用

吳 銳

(安徽省教育招生考試院 網(wǎng)絡信息中心， 安徽 合肥 230022)

互聯(lián)網(wǎng)用戶具有地理分布范圍廣、數(shù)量不確定、訪問突發(fā)性強等特點，Web應用系統(tǒng)在設計時很難模擬大量用戶同時訪問的場景，對并發(fā)負載狀態(tài)缺乏量化測量和監(jiān)控手段，正式運行后容易遇到訪問高峰而發(fā)生系統(tǒng)響應速度變慢甚至中斷等情況，鐵道部12306售票網(wǎng)站就是屢被詬病的典型案例.Web應用系統(tǒng)需在部署前精確測量并發(fā)性能、部署后實時監(jiān)控并發(fā)負載，根據(jù)運行前預估的和運行時實際的用戶并發(fā)訪問規(guī)模，合理部署、及時調(diào)整系統(tǒng)的軟硬件數(shù)量，保證用戶對系統(tǒng)的正常訪問.

1并發(fā)與性能指標

1.1Web應用系統(tǒng)的并發(fā)

Web應用系統(tǒng)一般采用B/S架構(gòu)，本文所研究的并發(fā)指的是系統(tǒng)在同一個時間段內(nèi)執(zhí)行的所有用戶HTTP請求和響應的總和，當這個時間段劃分為更小的時間片時，發(fā)出請求的用戶、HTTP請求和響應可能是不同的.

HTTP是基于TCP的應用層協(xié)議，Web應用系統(tǒng)并發(fā)也是系統(tǒng)和用戶之間所有TCP連接的總和，但一個HTTP請求可能因調(diào)用多個資源而產(chǎn)生多個TCP連接.每個TCP連接都會耗費系統(tǒng)一定數(shù)量的CPU使用率、內(nèi)存、互聯(lián)網(wǎng)帶寬等資源，內(nèi)存、互聯(lián)網(wǎng)帶寬很容易進行擴充，不應成為系統(tǒng)并發(fā)性能的瓶頸，執(zhí)行計算任務的CPU(包括服務器CPU、防火墻CPU等)是系統(tǒng)并發(fā)性能的決定因素[1].

1.2TCP連接狀態(tài)與并發(fā)性能指標

1.2.1TCP連接狀態(tài)

根據(jù)TCP/IP協(xié)議標準[2]，TCP連接有9種狀態(tài)(SYN-RECEIVED、ESTABLISHED、TIME-WAIT等).其中僅ESTABLISHED狀態(tài)TCP連接傳輸應用數(shù)據(jù)、執(zhí)行計算，對系統(tǒng)資源消耗較大；其他狀態(tài)的TCP連接大多數(shù)處于等待狀態(tài)，活動時也僅傳輸握手信號或關(guān)閉信號，對系統(tǒng)資源消耗很小.另外Linux 2.6以上版本內(nèi)核的epoll機制[3]，可顯著減少系統(tǒng)存在大量并發(fā)連接、只有少量連接活躍情況下的CPU使用率，使非ESTABLISHED狀態(tài)TCP連接對CPU的使用率進一步減小.

正常運行的Web應用系統(tǒng)會主動關(guān)閉與用戶的TCP連接，根據(jù)TCP狀態(tài)轉(zhuǎn)換圖，系統(tǒng)一般只大量出現(xiàn)ESTABLISHED、TIME-WAIT兩種狀態(tài)的TCP連接.對于TIME-WAIT狀態(tài)TCP連接，可在Linux/Windows操作系統(tǒng)中限制其最大數(shù)量，避免對系統(tǒng)資源的嚴重消耗.

HTTP協(xié)議開啟Keep-Alive特性可節(jié)省系統(tǒng)與同一用戶建立TCP連接過程的開銷.對于大量用戶短時間集中訪問的系統(tǒng)，采用Keep-Alive會導致系統(tǒng)被迫長時間保持大量ESTABLISHED狀態(tài)TCP連接，系統(tǒng)資源消耗反而變大.另外現(xiàn)代操作系統(tǒng)越來越先進，使建立TCP連接的開銷越來越小，如epoll機制.Keep-Alive也會造成ESTABLISHED狀態(tài)TCP連接的忙碌和空閑無法區(qū)分，ESTABLISHED狀態(tài)TCP連接數(shù)量與系統(tǒng)并發(fā)負載狀態(tài)的關(guān)聯(lián)度減小.所以本文討論的Web應用系統(tǒng)，關(guān)閉了HTTP的Keep-Alive特性.

Web應用系統(tǒng)中的一些服務器，可能是另外一些服務器的客戶端，TCP連接的被動關(guān)閉導致系統(tǒng)出現(xiàn)一定數(shù)量的CLOSE-WAIT狀態(tài)TCP連接，但對系統(tǒng)性能影響很小：(1)服務器對服務器的連接一般會采用連接池(connection pool)或持久化(persistent)等技術(shù)來提高性能，這種連接長時間保持ESTABLISHED狀態(tài)，不會出現(xiàn)連接狀態(tài)的經(jīng)常變化；(2)服務器對服務器的TCP連接總數(shù)有限，相比服務器與用戶之間動輒數(shù)千的TCP連接并發(fā)，數(shù)量微不足道.

在實踐中，Web應用系統(tǒng)也有可能出現(xiàn)大量SYN-RECEIVED狀態(tài)TCP連接，此時系統(tǒng)一般處于兩種狀態(tài)：遭到了SYN FLOOD攻擊、超負載運行導致與用戶的TCP連接3次握手變慢.

綜上所述，經(jīng)合理配置的系統(tǒng)在正常運行時，ESTABLISHED狀態(tài)TCP連接數(shù)量與系統(tǒng)運行負載密切相關(guān).

1.2.2并發(fā)性能指標

Web應用系統(tǒng)的并發(fā)性能，可從響應時間、吞吐量、用戶行為等方面進行研究[4]，本文從系統(tǒng)與用戶之間的TCP連接出發(fā)，提出以下衡量Web應用系統(tǒng)并發(fā)性能的4個指標：

1)PETC-Parallel Established TCP Connections.系統(tǒng)與用戶之間瞬時處于ESTABLISHED狀態(tài)的TCP連接數(shù)，PETC的最大值MPETC是衡量系統(tǒng)并發(fā)性能的最重要指標.

2)NTCPS-New TCP Connections Per Second.系統(tǒng)與用戶之間每秒新創(chuàng)建的TCP連接數(shù)，代表系統(tǒng)每秒響應用戶新請求的能力.

3)FETCPS-Finished Established TCP Connections Per Second.系統(tǒng)與用戶之間每秒結(jié)束ESTABLISHED狀態(tài)的TCP連接數(shù)，結(jié)合完成的總時間，可以計算出系統(tǒng)完成單個TCP連接所需的時間.

4)MFETCPS-Max Finished Established TCP Connections Per Second.系統(tǒng)與用戶之間每秒最多可完成的ESTABLISHED狀態(tài)TCP連接數(shù)，可根據(jù)FETCPS的單個TCP連接所需完成時間進行理論推算得出.

1.2.3系統(tǒng)運行狀態(tài)

隨著用戶每秒對Web應用系統(tǒng)TCP連接請求從無到有、逐漸增多，系統(tǒng)負載逐漸加大，PETC、NTCPS、FETCPS三項指標先逐漸增大、到了最大值后開始減小，MFETCPS指標一直減小，可將系統(tǒng)的運行狀態(tài)劃分為3個階段：

1)輕負載

當用戶每秒發(fā)出的TCP連接請求數(shù)較少時，系統(tǒng)CPU使用率小于100%，系統(tǒng)每秒可完成處理的ESTABLISHED狀態(tài)TCP連接數(shù)大于新創(chuàng)建的TCP連接數(shù)，并發(fā)性能指標之間的數(shù)量關(guān)系為：NTCPS=FETCPS

2)均衡負載

當用戶每秒發(fā)出的TCP連接請求數(shù)達到一定數(shù)量時，系統(tǒng)CPU使用率為100%，系統(tǒng)每秒新建的TCP連接數(shù)等于每秒完成處理并關(guān)閉的TCP連接數(shù)，系統(tǒng)處于吞吐動態(tài)平衡狀態(tài)，并發(fā)性能指標之間的數(shù)量關(guān)系為：NTCPS=FETCPS=MFETCPS，在TCP連接請求對時間均勻分布的前提下，PETC=NTCPS.將系統(tǒng)此運行狀態(tài)稱為最佳運行狀態(tài)，此時PETC達到最大值.理論上用戶向系統(tǒng)發(fā)出的MPETC個TCP連接，可在一秒之內(nèi)獲得所需的結(jié)果，用戶感覺不到系統(tǒng)響應的延時.

3)重負載

當用戶每秒發(fā)出的TCP連接請求數(shù)再加大，系統(tǒng)負載再加重，對用戶TCP請求的響應時間變長、甚至超時中斷，此時系統(tǒng)CPU使用率仍為100%，但系統(tǒng)被迫耗費更多的CPU資源去處理與用戶的TCP三次握手連接，用于處理ESTABLISHED狀態(tài)TCP連接的CPU資源反而減少，PETC、FETCPS、MFETCPS從最大值開始減小，并發(fā)指標之間的數(shù)量關(guān)系為：NTCPS>FETCPS=MFETCPS，在TCP連接請求對時間均勻分布的前提下，PETC>FETCPS，但PETC與NTCPS的大小關(guān)系不確定.

用戶每秒TCP連接請求數(shù)與PETC、MFETCPS兩項指標之間的數(shù)量關(guān)系如圖1所示.

圖1 TCP請求數(shù)與并發(fā)指標

2并發(fā)性能指標的測量方法

Web應用系統(tǒng)在運行時，存在著多個用戶對多種資源的多個請求，系統(tǒng)在響應這些差異化的請求時所耗費的CPU使用率、內(nèi)存、互聯(lián)網(wǎng)帶寬等資源相差很大，給測量系統(tǒng)并發(fā)性能帶來了挑戰(zhàn)，解決方案有兩種：

第一種，采用復雜的分布式測試方案，借助于商業(yè)測試軟件(如LoadRunner)模擬對Web應用系統(tǒng)的大規(guī)?；ヂ?lián)網(wǎng)訪問[5]，這種方案實施成本高，對復雜場景的模擬也存在困難.

第二種，將用戶HTTP請求、系統(tǒng)HTTP響應按照運行流程，分解成最小的、不可再分割的原子請求和響應集合，簡化測試場景，使用自編或開源軟件精確測量各類原子請求和響應的并發(fā)性能，再將這些原子請求和響應按并聯(lián)或串聯(lián)的方式進行組合計算，最后得出整個系統(tǒng)的并發(fā)性能[6].

本文采取的是第二種方案.

2.1原子分解與MPETC計算公式

按照以下三種分解方法，可將Web應用系統(tǒng)所有HTTP請求與響應分解為各類原子請求與響應集合，而原子請求和響應與TCP連接之間存在著一一對應關(guān)系，從而將并發(fā)性能測量轉(zhuǎn)換為對TCP連接數(shù)的測量.

2.1.1并行響應的分解

用戶向系統(tǒng)發(fā)出一個HTTP請求獲取資源A1，但A1需調(diào)用資源A2、…、An，系統(tǒng)需一次返回n個資源進行響應，這里的資源是個廣義的概念，可以是靜態(tài)網(wǎng)頁、動態(tài)網(wǎng)頁、圖片、驗證碼生成等.將資源A1改造為A1′，消除對資源A2、…、An的調(diào)用，該HTTP請求和響應分解成對資源A1′、A2、…、An的請求和響應H1、H2、…、Hn，如圖2所示，分別對這些請求和響應測量出最大并發(fā)數(shù)MPETC1、MPETC2、…、MPETCn.

圖2 并行響應的原子分解

計算得

(1)

2.1.2串行請求的分解

在動態(tài)交互系統(tǒng)中，用戶需按照一定的次序連續(xù)發(fā)出請求：H1、H2、…、Hn，才能獲得所需要的最終資源An.將請求H1、H2、…、Hn改造為請求H1、H2′、…、Hn′，發(fā)出請求Hk′(k=2,…,n)時，攜帶請求H1、H2、…Hk-1的響應結(jié)果，消除Hk′對前面k-1個請求的依賴，使得這n個請求彼此獨立，如圖3所示，這種改造并不會改變每個請求的最大并發(fā)數(shù)，對每個請求H1、H2′、…、Hn′，分別測量出最大并發(fā)數(shù)MPETC1、MPETC2、…、MPETCn.

圖3 串行請求的原子分解

假設原系統(tǒng)處于最佳運行狀態(tài)有MPETC個并發(fā)，則請求H1、H2、…、Hn的并發(fā)數(shù)是相同的，論證如下：因為用戶數(shù)量足夠多、操作彼此獨立，假設請求Hk的并發(fā)數(shù)PETCk最小，則Hk之后的請求因處理速度較快、被Hk請求阻塞，并發(fā)數(shù)自動降為PETCk，釋放了部分CPU資源可用于處理Hk請求；Hk之前的請求因處理速度較快，在Hk請求處產(chǎn)生瓶頸，部分用戶因系統(tǒng)響應變慢而處于等待狀態(tài)，阻塞了新用戶對系統(tǒng)發(fā)出的新請求，系統(tǒng)負載減小，系統(tǒng)對請求Hk的處理速度加快，最終PETCk與前面k-1請求的并發(fā)數(shù)相同.同理可得公式(1).

2.1.3并行請求的分解

計算得

(2)

特別對于所有資源都被等概率(Pi=1/n，i=1…n)訪問的特殊情形，公式(2)即為公式(1).

2.2測量方法

對并發(fā)指標的測量，可使用基于監(jiān)控和基于測試軟件兩種方法，基于監(jiān)控適和對系統(tǒng)各個時刻的PETC、NTCPS進行連續(xù)測量，結(jié)合Cacti數(shù)據(jù)采集和繪圖軟件可獲取該并發(fā)指標在任意時刻的數(shù)值和圖形[8]；基于測試軟件適合對FETCPS、MFETCPS進行有限次測量來確定MPETC.

2.2.1PETC的測量

(1)基于SNMP監(jiān)控

SNMP[9]的tcpCurrEstab(OID:1.3.6.1.2.1.6.9)監(jiān)控值代表系統(tǒng)中ESTABLISHED和CLOSE-WAIT兩種狀態(tài)的TCP連接總數(shù)，前文已經(jīng)論述了在Web應用系統(tǒng)服務器中CLOSE-WAIT狀態(tài)TCP連接數(shù)為零或極少，但tcpCurrEstab值不能直接作為PETC值，在多層架構(gòu)的系統(tǒng)中，用戶與系統(tǒng)第一層建立一個TCP連接，第一層會依次與其他層建立TCP連接，這些連接的生命周期相同，連接的總數(shù)與系統(tǒng)的層數(shù)相關(guān)，此時tcpCurrEstab值與PETC值呈倍數(shù)關(guān)系.

(2)基于應用軟件監(jiān)控

一些應用軟件內(nèi)置了與用戶建立的ESTABLISHED狀態(tài)TCP連接數(shù)監(jiān)控，可直接獲取PETC值，如Nginx軟件的NginxStatus監(jiān)控.

2.2.2NTCPS的測量

SNMP的tcpPassiveOpens(OID:1.3.6.1.2.1.6.6)監(jiān)控值代表系統(tǒng)中TCP端口由LISTEN狀態(tài)轉(zhuǎn)變?yōu)镾YN-RECEIVED狀態(tài)的數(shù)量，與PETC的情形類似，該數(shù)值與NTCPS值呈倍數(shù)關(guān)系.

2.2.3FETCPS和MFETCPS的測量

對Web應用系統(tǒng)的HTTP請求和響應進行原子分解后，降低了并發(fā)性能測試軟件的復雜度，對于每個原子請求和響應，可使用簡單的并發(fā)性能測試軟件向系統(tǒng)發(fā)出一定并發(fā)數(shù)量的原子HTTP請求，結(jié)合完成這些請求實際所需的總時間，得出該并發(fā)數(shù)量下的FETCPS和MFETCPS.

開源軟件Apache自帶的ab[10]可用于測量原子請求和響應的MFETCPS，使用的命令格式為：ab -c c0-n n0 http://ip/index.html，其中參數(shù)c0為并行請求數(shù)、n0為請求總數(shù)，ab軟件采用的測試策略是前一個請求被系統(tǒng)響應完畢就立即發(fā)出一個新請求，在c0個并行請求的前提下，對系統(tǒng)發(fā)出盡可能多的請求數(shù).所以命令執(zhí)行完畢后輸出的結(jié)果中：“Time per request”數(shù)值t0是系統(tǒng)完成每個TCP連接所需要的時間、“Requests per second”數(shù)值r0即為MFETCPS.

2.2.4MPETC的測量

基于監(jiān)控和ab軟件都能測量出MPETC數(shù)值，但基于ab軟件的測量更快捷，可采用二分查找法：

1)發(fā)出一個較小的并行請求數(shù)C1，測得MFETCPS1，此時C1

2)發(fā)出一個很大的并行請求數(shù)C2，測得MFETCPS2，此時C2>MFETCPS2.

3)發(fā)出并行請求數(shù)C3=(C1+C2)/2，測得MFETCPS3，若C3=MFETCPS3，則MPETC值為C3，否則根據(jù)C3和MFETCPS3的大小關(guān)系重復以上步驟.

3高考網(wǎng)上查分系統(tǒng)并發(fā)性能測量

3.1查分系統(tǒng)概況

查分系統(tǒng)采用公認的動態(tài)網(wǎng)頁并發(fā)性能最高的Linux/Nginx/PHP軟件組合并進行了設計優(yōu)化[11-12]，系統(tǒng)架構(gòu)如圖4所示.負載均衡器后端是多臺查分服務器，所有查分服務器共用Oracle數(shù)據(jù)庫服務器，查分服務器的硬件配置為1顆4核3.0GHz主頻CPU、4G內(nèi)存，Oracle數(shù)據(jù)庫服務器硬件配置為2顆4核2.4GHz主頻CPU、16G內(nèi)存.

圖4 高考網(wǎng)上查分系統(tǒng)架構(gòu)

查分系統(tǒng)對外開放前，首頁是一個html靜態(tài)頁面，發(fā)布提示信息給考生.查分系統(tǒng)對外開放后，首頁是一個php動態(tài)頁面，需考生輸入座位號、身份證號、驗證碼，發(fā)送給php分數(shù)查詢動態(tài)頁面，獲得分數(shù)結(jié)果.

在計算復雜度確定的前提下，Web頁面的并發(fā)數(shù)與頁面長度直接相關(guān)，本查分系統(tǒng)涉及的所有頁面大小控制在5KB左右，除了驗證碼的圖片，不包含其他任何圖片，否則系統(tǒng)對互聯(lián)網(wǎng)帶寬需求太大.

Cacti系統(tǒng)每隔1min采集一次PETC、NTCPS、CPU使用率等監(jiān)控值并繪圖。

3.2MPETC的測量

3.2.1 查分服務器

靜態(tài)首頁僅含靜態(tài)文字，無需進行原子分解；信息輸入和分數(shù)查詢兩個動態(tài)頁面必須按順序運行，按串行請求方式進行原子分解和公式計算；信息輸入頁面內(nèi)含文字提示和驗證碼圖片兩個資源，ab軟件無法在一次請求中獲取這兩個資源，按并行響應方式進行原子分解和公式計算。

1)靜態(tài)頁面

按前文所述的二分查找法測量靜態(tài)頁面的MPETC為1.06萬，見表1，ab的命令格式為：ab -c c0 -n n0 http://ip/index.html，c0的起始最小、最大值選為1000、16000，n0為600萬，保證測試的持續(xù)時間為10min左右.

表1ab軟件二分查找法測量MPETC

2)信息輸入頁面

3)分數(shù)輸出頁面

分數(shù)輸出頁面out.php的運行依賴于信息輸入頁面index.php以POST方式提交的座位號、身份證號、驗證碼參數(shù)，測試時修改out.php代碼，使其可從測試命令行獲得以GET方式提交的參數(shù)，ab的命令格式為ab -c c0 -n n0 http://ip/out.php?zwh=zwh0&sfzh=sfzh0&code=code0，同樣使用二分查找法測得每臺服務器分數(shù)輸出頁面的MPETC為2810.

4)查分服務器

3.2.2防火墻和負載均衡器

防火墻、負載均衡器等網(wǎng)絡設備的并發(fā)性能也制約了Web應用系統(tǒng)對用戶可提供的并發(fā)性能，網(wǎng)絡設備對于任何TCP連接，只提供數(shù)據(jù)傳輸功能、不執(zhí)行任何計算，并發(fā)性能僅與TCP連接傳輸?shù)臄?shù)據(jù)長度有關(guān).可采用黑盒測試的方式對網(wǎng)絡設備并發(fā)指標進行測量[13]，如圖5所示.對于不同的資源Ak，發(fā)出測試請求H1，當網(wǎng)絡設備CPU使用率為100%時，并發(fā)數(shù)PETCk即為網(wǎng)絡設備對資源Ak請求的MPETC.若網(wǎng)絡設備并發(fā)性能較好，可根據(jù)實際情況發(fā)出多路測試請求H2、…、Hm.

圖5 網(wǎng)絡設備并發(fā)性能指標的測量

在網(wǎng)頁長度5KB的情形下，本系統(tǒng)使用的某款防火墻和負載均衡器的MPETC值分別為1.02萬、1.36萬.

3.3并發(fā)指標與硬件數(shù)量

在本系統(tǒng)中，防火墻和負載均衡器各一臺，無法通過增加數(shù)量來提高并發(fā)指標，這決定了整個系統(tǒng)對互聯(lián)網(wǎng)用戶可提供的最大PETC即為防火墻的MPETC：1.02萬.

3.3.1查分服務器數(shù)量

所有查分服務器的MPETC總和達到1.02萬即可，靜態(tài)網(wǎng)頁服務器只需要1臺(1.06萬)、動態(tài)網(wǎng)頁查分服務器需要3臺(3577×3=10731).

3.3.2Oracle數(shù)據(jù)庫服務器數(shù)量

在對單臺查分服務器MPETC測量時，Cacti監(jiān)控顯示分數(shù)查詢引起的Oracle數(shù)據(jù)庫服務器CPU使用率為4%，3臺查分服務器同時運行時，Oracle數(shù)據(jù)庫服務器CPU使用率為12%，使用1臺Oracle數(shù)據(jù)庫服務器即可滿足系統(tǒng)需要.

3.3.3互聯(lián)網(wǎng)帶寬

查分系統(tǒng)對互聯(lián)網(wǎng)帶寬的最大需求為408Mbits(=1.02萬×5KB×8)，遠大于現(xiàn)有的200Mbits互聯(lián)網(wǎng)帶寬，解決方案有2種：

1)增加3條100M寬帶，這會增加額外的費用.

2)查分服務器啟用Nginx靜態(tài)html網(wǎng)頁和動態(tài)php網(wǎng)頁的HTTP壓縮傳輸，對于純文本信息的網(wǎng)頁，可節(jié)省50%以上的帶寬，但壓縮傳輸會消耗一些CPU使用率，尤其是動態(tài)php網(wǎng)頁的壓縮傳輸可導致服務器MPETC下降約25%，可通過增加1臺動態(tài)php網(wǎng)頁查分服務器來保持系統(tǒng)MPETC不減少.

3.3.4運行效果

綜上所述，查分系統(tǒng)最終采用4臺查分服務器、1臺Oracle數(shù)據(jù)庫服務器，系統(tǒng)MPETC為1.02萬，每秒有5 100個考生可查出分數(shù)結(jié)果，預計全省50萬考生可在98s之內(nèi)完成查分.

安徽省2012年高考網(wǎng)上查分系統(tǒng)實際運行時，Cacti監(jiān)控表明系統(tǒng)PETC最大值不超過7 000，小于設計指標1.02萬。所有查分的考生都可在信息輸入后1s之內(nèi)查出分數(shù)結(jié)果，獲得良好的社會反響.

4結(jié)束語

本文提出的HTTP請求和響應的原子分解策略，簡化了并發(fā)性能測試的場景，降低了并發(fā)性能測試軟件的復雜度，便于精確定位系統(tǒng)并發(fā)性能瓶頸，有針對性地進行優(yōu)化設計.本文提出的并發(fā)性能指標，在系統(tǒng)設計時可定量確定并發(fā)性能，在系統(tǒng)運行時可實時監(jiān)控并發(fā)負載狀態(tài)，為保障系統(tǒng)正常運行打下基礎.

[1] 李邐. Web項目性能測試實例設計與分析[J].遼寧高職學報,2009,11(9):89-92.

[2] Stevens W R.TCP/IP詳解卷1:協(xié)議[M].北京：機械工業(yè)出版社,2000:174-191.

[3] 張軼凡，盧正興，王芙蓉. Linux下高性能網(wǎng)絡I/O解決方案分析[J].現(xiàn)代計算機,2006(247):90-93.

[4] 蘭景英，王永恒. Web性能測試研究[J].計算機技術(shù)與發(fā)展,2008,18(11):90-93.

[5] 左為平，楊曉亞. WEB應用系統(tǒng)性能測試的實現(xiàn)[J].重慶科技學院學報：自然科學版,2012,14(1):131-132.

[6] 賀樂天，孫永強. 分布式計算的并發(fā)測量[J].軟件學報,1998,9(1):30-35.

[7] 劉荷花. Web性能測試的實現(xiàn)方法[J].山西電子技術(shù),2010(1):64-65.

[8] The Cacti Group Inc. Cacti Manual [EB/OL]. (2012)[2012-6-25]. http://www.cacti.net/downloads/docs/html/index.html.

[9] 武孟軍. 精通SNMP[M]. 北京：人民郵電出版社,2010.

[10] 邵芬，于國防，付海燕. AB：一種簡單的性能測試工具[J].計算機時代,2007(12):59-60.

[11] 張宴.實戰(zhàn)Nginx：取代Apache的高性能Web服務器[M]. 北京：電子工業(yè)出版社,2010.

[12] 李軍.高并發(fā)Web系統(tǒng)的設計與優(yōu)化[D].北京：北京交通大學,2009.

[13] 楊建光，梅大成.黑盒測試方法和綜合策略的研究[J].計算機光盤軟件與應用,2012(1):121-122.