Web應用系統并發性能測量的研究與應用

吳 銳

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

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

1并發與性能指標

1.1Web應用系統的并發

Web應用系統一般采用B/S架構，本文所研究的并發指的是系統在同一個時間段內執行的所有用戶HTTP請求和響應的總和，當這個時間段劃分為更小的時間片時，發出請求的用戶、HTTP請求和響應可能是不同的.

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

1.2TCP連接狀態與并發性能指標

1.2.1TCP連接狀態

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

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

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

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

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

綜上所述，經合理配置的系統在正常運行時，ESTABLISHED狀態TCP連接數量與系統運行負載密切相關.

1.2.2并發性能指標

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

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

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

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

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

1.2.3系統運行狀態

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

1)輕負載

當用戶每秒發出的TCP連接請求數較少時，系統CPU使用率小于100%，系統每秒可完成處理的ESTABLISHED狀態TCP連接數大于新創建的TCP連接數，并發性能指標之間的數量關系為：NTCPS=FETCPS

2)均衡負載

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

3)重負載

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

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

圖1 TCP請求數與并發指標

2并發性能指標的測量方法

Web應用系統在運行時，存在著多個用戶對多種資源的多個請求，系統在響應這些差異化的請求時所耗費的CPU使用率、內存、互聯網帶寬等資源相差很大，給測量系統并發性能帶來了挑戰，解決方案有兩種：

第一種，采用復雜的分布式測試方案，借助于商業測試軟件(如LoadRunner)模擬對Web應用系統的大規模互聯網訪問[5]，這種方案實施成本高，對復雜場景的模擬也存在困難.

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

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

2.1原子分解與MPETC計算公式

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

2.1.1并行響應的分解

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

圖2 并行響應的原子分解

計算得

(1)

2.1.2串行請求的分解

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

圖3 串行請求的原子分解

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

2.1.3并行請求的分解

計算得

(2)

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

2.2測量方法

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

2.2.1PETC的測量

(1)基于SNMP監控

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

(2)基于應用軟件監控

一些應用軟件內置了與用戶建立的ESTABLISHED狀態TCP連接數監控，可直接獲取PETC值，如Nginx軟件的NginxStatus監控.

2.2.2NTCPS的測量

SNMP的tcpPassiveOpens(OID:1.3.6.1.2.1.6.6)監控值代表系統中TCP端口由LISTEN狀態轉變為SYN-RECEIVED狀態的數量，與PETC的情形類似，該數值與NTCPS值呈倍數關系.

2.2.3FETCPS和MFETCPS的測量

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

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

2.2.4MPETC的測量

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

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

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

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

3高考網上查分系統并發性能測量

3.1查分系統概況

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

圖4 高考網上查分系統架構

查分系統對外開放前，首頁是一個html靜態頁面，發布提示信息給考生.查分系統對外開放后，首頁是一個php動態頁面，需考生輸入座位號、身份證號、驗證碼，發送給php分數查詢動態頁面，獲得分數結果.

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

Cacti系統每隔1min采集一次PETC、NTCPS、CPU使用率等監控值并繪圖。

3.2MPETC的測量

3.2.1 查分服務器

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

1)靜態頁面

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

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

2)信息輸入頁面

3)分數輸出頁面

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

4)查分服務器

3.2.2防火墻和負載均衡器

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

圖5 網絡設備并發性能指標的測量

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

3.3并發指標與硬件數量

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

3.3.1查分服務器數量

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

3.3.2Oracle數據庫服務器數量

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

3.3.3互聯網帶寬

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

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

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

3.3.4運行效果

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

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

4結束語

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

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

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

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

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

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

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

[7] 劉荷花. Web性能測試的實現方法[J].山西電子技術,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] 張宴.實戰Nginx：取代Apache的高性能Web服務器[M]. 北京：電子工業出版社,2010.

[12] 李軍.高并發Web系統的設計與優化[D].北京：北京交通大學,2009.

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