Ｗｅｂ集群系統(tǒng)性能測試與優(yōu)化

摘要：如何對Web集群應用進行測試及優(yōu)化成為日益迫切的問題。結合一個實際的Web應用案例，討論了如何利用測試工具測試Web集群應用的性能以及如何分析測試結果，給出Web集群應用性能優(yōu)化的方案。

關鍵詞：Web集群應用； 性能； 測試； 優(yōu)化

中圖分類號：TP393.06文獻標志碼：A

文章編號：1001－3695(2008)03－0826－03

0引言

隨著互聯(lián)網(wǎng)的日益普及和電子商務的逐漸興起，各類基于Web的應用程序以其方便、快速，易操作等特點不斷成為軟件開發(fā)的重點。同時，隨著需求量與應用領域的不斷擴大，出現(xiàn)了越來越多的大型Web應用，如門戶網(wǎng)站、網(wǎng)上銀行等。這些Web應用的最大特點就是訪問人數(shù)眾多，并發(fā)訪問量大。這就對Web應用的性能，特別是高并發(fā)條件下的性能提出了越來越高的要求。

提高Web應用性能的重要手段是采用Web應用服務器集群技術。Web應用服務器集群是由一群同時運行同一個Web應用的服務器組成的集群系統(tǒng)，在外界看來，就像是一個服務器。集群服務器將眾多的訪問請求分散到系統(tǒng)中的不同節(jié)點進行處理，從而提高了整個應用的有效性和穩(wěn)定性。但是如果單個節(jié)點的性能出現(xiàn)瓶頸，極有可能造成連鎖反應，降低整個集群的性能。對Web集群的性能測試能夠確定影響Web集群性能的關鍵因素，從而可以有針對性地進行分析和改進，避免Web應用優(yōu)化過程中的盲目行為。因此，對Web集群應用進行有效的、系統(tǒng)的測試逐漸成為人們研究的重要課題。

一個Web集群應用的測試過程可以大致分為功能測試、性能測試、可用性測試、客戶端兼容性測試和安全性測試五個部分；性能測試分為連接速度測試、負載測試、壓力測試三個部分。

Web集群應用的功能測試、可用性測試、客戶端兼容性測試和安全性測試比較簡單，難點是如何進行性能測試。本文將首先討論Web應用性能測試的相關問題，最后結合某市2006年普通高等學校志愿網(wǎng)上填報系統(tǒng)，討論如何根據(jù)測試結果進行系統(tǒng)優(yōu)化。

高考志愿網(wǎng)上填報工作受到廣大考生、考生家長和教育部的關注，而志愿填報系統(tǒng)運行正常與否則是整個志愿填報工作成敗的關鍵，所以系統(tǒng)正式運行前必須進行大量測試。2007年該市高考考生超過了17萬人，網(wǎng)上志愿填報時間僅為3天，系統(tǒng)將承受較大的負載，所以測試的主要任務就是測試系統(tǒng)在高并發(fā)條件下的性能。

1Web集群應用性能測試

1．1性能測試分類

1．1．1連接速度測試

用戶連接到 Web 應用系統(tǒng)的速度根據(jù)上網(wǎng)方式的變化而變化，他們或許是電話撥號，或是寬帶上網(wǎng)。如果Web系統(tǒng)響應時間太長，用戶就會因沒有耐心等待而離開。另外，有些頁面有超時的限制，如果響應速度太慢，用戶可能還沒來得及瀏覽內容就需要重新登錄。而且，連接速度太慢還可能引起數(shù)據(jù)丟失，使用戶得不到真實的頁面。

1．1．2負載測試

負載測試是為了測量Web系統(tǒng)在某一負載級別上的性能，以保證Web系統(tǒng)在需求范圍內能正常工作。負載級別可以是某個時刻同時訪問Web系統(tǒng)的用戶數(shù)量，也可以是在線數(shù)據(jù)處理的數(shù)量。

1．1．3壓力測試

壓力測試是指實際破壞一個 Web 應用系統(tǒng)，測試系統(tǒng)的反應。壓力測試是測試系統(tǒng)的限制和故障恢復能力，即測試Web應用系統(tǒng)會不會崩潰，在什么情況下會崩潰。

1．2性能測試步驟

一個Web集群應用的性能測試大致由以下幾個部分組成：

a)分析Web應用結構，明確性能測試的需求，包括并發(fā)、極限、配置和指標等方面的性能要求。

b)分析應用場景和用戶數(shù)據(jù)，細分用戶行為和相關的數(shù)據(jù)流，確定測試點或測試接口，列出系統(tǒng)接口的可能瓶頸。

c)完成性能測試用例設計、分類選擇和依據(jù)用戶行為分析設計測試規(guī)程，并準備好測試用例將用到的測試數(shù)據(jù)。

d)確定采用的測試工具。

e)進行初驗測試，根據(jù)測試結果分析性能瓶頸，通過迭代保證基本的指標等測試的環(huán)境。

f)迭代進行全面的性能測試，完成計劃中的性能測試用例的執(zhí)行。

g)完成性能測試評估報告。

1．3性能測試指標

1)Processor time服務器CPU占用率。

2)Response delay應答延遲，一個請求從建立網(wǎng)絡連接到應答結束拆除連接之間的時間。

3)Hits per second每秒點擊次數(shù)。

4)Average response per second平均每秒鐘響應次數(shù)。

5)Database CPU processor time數(shù)據(jù)庫服務器CPU占用率。

6)Response time響應時間。

其中：Response time這一項指標是前五項性能測試指標的綜合反映。

1．4性能測試工具

Web性能測試主要是利用軟件來模擬用戶的操作行為和用戶的數(shù)量。比較流行的測試工具有LoadRunner、OpenSTA、Rational Robot、WebLoad等。這些軟件可以通過配置腳本，模擬真實用戶的操作，自動測試Web應用，并得到測試結果。下面主要介紹LoadRunner。

LoadRunner可以自動記錄用戶的操作來形成vuser(虛擬用戶)測試腳本，通過設置vuser的數(shù)量來模擬大量用戶使用Web應用。為了模擬高并發(fā)環(huán)境，用戶還可以在腳本中插入循環(huán)和集合點。循環(huán)就是在腳本中指定操作的起點和終點，vuser在這兩點之間重復執(zhí)行記錄下來的用戶操作，用戶可以設定循環(huán)的次數(shù)。集合點是一個并發(fā)訪問的點，在測試需求中，可能會要求系統(tǒng)能夠承受1 000人同時提交數(shù)據(jù)，1 000人同時保存單據(jù)。在LoadRunner中可以通過在提交數(shù)據(jù)操作前加入集合點，這樣當vuser運行到提交數(shù)據(jù)的集合點時，LoadRunner就會檢查同時有多少vuser運行到集合點，如果不到1 000人，LoadRunner就會命令已到集合點的vuser在此等待，當在集合點等待的vuser達到1 000人，LoadRunner命令1 000人同時去提交數(shù)據(jù)，達到并發(fā)訪問的目的。

下面以該市2006年普通高等學校志愿網(wǎng)上填報應用系統(tǒng)作為測試對象，填報系統(tǒng)采用J2EE技術編寫，采用CMP做數(shù)據(jù)庫的對象——關系映射，填報志愿操作部分采用安全套接字層 (SSL)連接。測試工具選擇LoadRunner，通過

軟件模擬的方式，測試系統(tǒng)在不同數(shù)量用戶、不同操作行為下的反應，并通過分析測試結果找出系統(tǒng)優(yōu)化方法。

2測試過程和結果分析

2．1測試準備

經過對填報人數(shù)和學生填報行為的分析預測，正式填報時單臺服務器的負載最高將達到2 000人。所以測試要求單臺應用服務器能支持同時在線2 000人訪問。根據(jù)系統(tǒng)功能情況，估計性能瓶頸在志愿填報模塊。

首先以學生用戶的身份登錄系統(tǒng)，完成各項操作，最后退出系統(tǒng)，LoadRunner記錄各項操作，并形成一份測試腳本。測試腳本分為登錄系統(tǒng)、業(yè)務操作和退出系統(tǒng)三大部分。登錄系統(tǒng)部分負責驗證考生的密碼和考生是否處于填報時間內；退出部分負責釋放系統(tǒng)資源；為了能準確定位系統(tǒng)瓶頸，業(yè)務操作又細分為考生基本信息查詢、志愿填報、志愿查詢三部分。為了能測試系統(tǒng)在高并發(fā)下的性能，在每個部分開始前均設置了集合點，等在業(yè)務操作中設置了循環(huán)。

整個測試將采用迭代策略：先以一定數(shù)量的vuser按照測試腳本測試，針對測試結果進行性能調整后繼續(xù)增加vuser數(shù)量進行測試；最后得到針對不同用戶量的最佳軟硬件配置方案。

2．2測試環(huán)境

應用服務器為JBoss，操作系統(tǒng)為Linux，數(shù)據(jù)庫為Oracle。填報時使用十臺應用服務器構建應用服務器集群，使用一臺數(shù)據(jù)庫服務器。測試時使用局域網(wǎng)，使用三臺PC機運行測試腳本，采用三臺應用服務器作為集群。測試時的結構圖如圖1所示。

2．3測試結果

測試時每個計算機運行的測試腳本使用的vuser數(shù)量分別為250、500、1 000和2 000，測試使用的測試腳本為一個理科考生的正常填報過程。其中在考生基本信息查詢、志愿填報、志愿查詢操作前分別加入了集合點。表1為測試計算機1在不同vuser數(shù)量下測試的Web服務器應答狀態(tài)情況。

注：HTTP應答返回狀態(tài)代碼200表示一切正常；

請求超時或服務器拒絕請求（HTTP）表示HTTP的連接端口連接不上；

請求超時或服務器拒絕請求（HTTPS）表示HTTPS的連接端口連接不上；

HTTP應答返回狀態(tài)代碼500表示服務器遇到了意料不到的情況，不能完成客戶的請求。

評價一個Web系統(tǒng)性能非常重要的指標就是操作的響應時間。LoadRunner可以根據(jù)需要記錄每個操作的響應時間。筆者記錄了考生使用最頻繁的三個操作，即信息查詢（Xxcy_Transaction）、志愿查詢（Zycy_Transaction）和志愿填報（Zytb_Transaction）操作。圖2為vuser為2 000時，志愿填報系統(tǒng)的平均事務響應時間圖。

2．4測試結果分析

根據(jù)Mercury公司的報告，網(wǎng)站性能問題可能由許多因素引起。但是，大約一半的性能問題是由于網(wǎng)絡、Web應用程序、Web服務器和數(shù)據(jù)庫服務器引起的。對數(shù)據(jù)庫操作依賴性很大的動態(tài)網(wǎng)站出現(xiàn)性能問題的風險尤其大。

測試時使用的網(wǎng)絡環(huán)境為局域網(wǎng)，而系統(tǒng)正式使用時的網(wǎng)絡環(huán)境為100 Mbps電信和網(wǎng)通專線接入，因此可以排除網(wǎng)絡對系統(tǒng)性能的影響。數(shù)據(jù)庫服務器使用的配置較高，并且測試時數(shù)據(jù)庫服務器的CPU占用率和內存使用率均保持在正常狀態(tài)，因此也可以排除數(shù)據(jù)庫服務器對性能的影響。

根據(jù)以上分析，將性能瓶頸定位在Web程序、數(shù)據(jù)庫和應用服務器配置上。

根據(jù)表1的結果，在并發(fā)數(shù)較多的情況下，出現(xiàn)了較多Web服務器連接超時和拒絕請求的情況，判斷是由于Web服務器連接人數(shù)限制造成的。根據(jù)圖2的結果，發(fā)現(xiàn)在高并發(fā)的情況下，操作的響應時間過長，按照定位的性能瓶頸，依次檢查Web程序、數(shù)據(jù)庫和應用服務器配置。

Web程序主要檢查數(shù)據(jù)庫訪問層的代碼。由于采用EJB的CMP，數(shù)據(jù)庫的訪問和連接均由JBoss負責，可以排除程序對性能的影響。

常見的數(shù)據(jù)庫問題有低效的索引設計、分割的數(shù)據(jù)庫、大量的連接操作等。

由于采用了EJB的CMP，與數(shù)據(jù)庫的連接和同步由JBoss負責管理，減小了對數(shù)據(jù)庫服務器的壓力，但增大了應用服務器的負擔。將數(shù)據(jù)庫的表均映射成了對象，加大了應用服務器上的內存消耗，筆者判斷主要是應用服務器造成了系統(tǒng)的性能瓶頸。

3系統(tǒng)優(yōu)化及性能分析

3．1優(yōu)化方案

3．1．1應用服務器配置

根據(jù)上述分析結果，修改JBoss服務器連接人數(shù)限制，如表2所示。

作出這樣的修改主要是參考服務器的硬件配置和實際的負載需求，過多的HTTP連接會消耗服務器的資源，尤其是HTTPS會很快地用盡系統(tǒng)資源并導致系統(tǒng)瓶頸。

同時修改應用服務器JBoss的內存使用量。修改前為最小128 MB，最大512 MB；修改后為最小512 MB，最大1 536 MB。作出這樣的修改主要是參考服務器的硬件配置，一般將內存最大占用量設為物理內存的80%。

3．1．2優(yōu)化數(shù)據(jù)庫設計

檢查表的索引，發(fā)現(xiàn)部分表的索引設計不合理，為部分表的字段增加索引。對個別頻繁訪問多表的過程，在主表內增加部分冗余數(shù)據(jù)，避免多表查詢。

3．1．3修改部分表的實體Bean屬性

采用CMP做數(shù)據(jù)庫的對象——關系映射時，數(shù)據(jù)庫中的表被映射成實體Bean對象，由JBoss負責同步數(shù)據(jù)庫表和實體Bean。有些數(shù)據(jù)庫表只涉及查詢操作，不涉及添加、刪除和更新，應該在JBoss中將這些表對應的實體Bean的屬性設為只讀，避免JBoss耗費資源同步實體Bean和數(shù)據(jù)庫表。修改后，將信息查詢這些只做查詢的表均設置成只讀屬性。

3．2優(yōu)化結果

進行系統(tǒng)調優(yōu)后，對vuser為2 000的情況再次進行了測試，測試結果如表3所示。對比表1和3，優(yōu)化后性能得到大幅提升。

4結束語

通過高負載測試，筆者找到了系統(tǒng)性能瓶頸并進行了優(yōu)化。雖然某些事務響應時間仍然較高，但這是每個測試腳本模擬2 000個客戶端瞬時訪問數(shù)據(jù)庫的情況，而且在這種情況下，應用服務器和數(shù)據(jù)庫服務器均工作正常，更增加了我們對實際填報工作順利完成的信心。

在正式填報中，數(shù)據(jù)庫和應用服務器均運行正常，沒有出現(xiàn)任何異常情況，圓滿完成了該市2006年普通高等學校志愿網(wǎng)上填報任務，充分證明了測試工作的有效性。

參考文獻：

[1]KILLELEA P.Web性能優(yōu)化[M]. 謝文亮，等譯.2版.北京:清華大學出版社，2003:15118.

[2]ASH L.Web測試指南[M].李昂，等譯.北京:機械工業(yè)出版社.2004:22－50.

[3]ALLAMARAJU S. J2EE服務器端高級編程[M]. 聞道工作室，譯.北京:機械工業(yè)出版社，2001:76－92.

[4]趙慶斌，馬素霞，趙慶玉. 網(wǎng)絡測試深入解析[M]. 北京:清華大學出版社， 2003:10－35.

[5]NGUYEN H Q.Web應用測試[M]. 周志榮，等譯.2版.北京:電子工業(yè)出版社，2005:23－67.

[6]陳紹英，夏海濤，金成姬. Web性能測試實戰(zhàn)[M]. 北京:電子工業(yè)出版社， 2006:8－64.

[7]JBoss Group. JBoss application server documentation library[EB/OL]. (2003－05－28).[20061218].http://labs.jboss.com/portal/jbossas/docs/index.html.

[8]張友生. 基于Web 的系統(tǒng)測試方法[EB/OL]. (2003－04－23).[20061218].http://industry.ccidnet.com/art/737/20030423/44625_1.html.

“本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文”