摘要：負載對應(yīng)用服務(wù)器系統(tǒng)老化有很大影響。為了揭示這種現(xiàn)象，設(shè)計了實驗方案，通過改變實驗參數(shù)，得到結(jié)論：內(nèi)存消耗是應(yīng)用服務(wù)器系統(tǒng)老化的主要原因，而負載的輕重對應(yīng)用服務(wù)器系統(tǒng)老化速度有直接的影響。該結(jié)果可作為實驗數(shù)據(jù)分析的基礎(chǔ)。

關(guān)鍵詞：老化；內(nèi)存消耗；已用內(nèi)存；負載

0 引言

應(yīng)用服務(wù)器是分布式網(wǎng)絡(luò)環(huán)境下，為應(yīng)用提供企業(yè)資源集成、事務(wù)處理、業(yè)務(wù)組件管理和部署等基礎(chǔ)服務(wù)的支撐平臺，其技術(shù)發(fā)展十分迅速。但是，服務(wù)器的性能衰退乃至服務(wù)器崩潰嚴重地制約了服務(wù)器的可靠性，如何構(gòu)建強壯、可靠、高性能的應(yīng)用服務(wù)器平臺是一個需要解決的問題。

以往，人們對通信系統(tǒng)的可靠性研究往往著眼于硬件的可靠性，隨著軟件在整個系統(tǒng)中的地位不斷上升，軟件可靠性問題已經(jīng)成為制約系統(tǒng)可靠性發(fā)展的主要瓶頸。隨著軟件規(guī)模的增大以及軟件重用的普及，排除軟件系統(tǒng)中所有的缺陷變得越來越不可能。在運行過程中，這些缺陷隨著時間逐漸累積，會導(dǎo)致軟件的性能下降，最終造成系統(tǒng)失效和停機。這一過程就稱為軟件老化。近年來的研究結(jié)果表明，許多軟件系統(tǒng)都存在老化現(xiàn)象。

為了抵消軟件老化造成的影響，眾多文獻對軟件老化進行了研究。但這些文獻基本上集中在研究操作系統(tǒng)的老化上，對應(yīng)用服務(wù)器中間件的老化研究均未涉及。本文采用測量的方法對一個實際的應(yīng)用服務(wù)器進行實驗，考察負載對系統(tǒng)老化的影響。通過對實驗結(jié)果的分析，發(fā)現(xiàn)負載的輕重對軟件老化的速度有重大影響。該結(jié)論可作為實驗數(shù)據(jù)分析的基礎(chǔ)。

1 實驗環(huán)境的構(gòu)建

實驗環(huán)境由三臺計算機構(gòu)成。一臺作為測試服務(wù)器(CPU 2.G Hz，內(nèi)存2G)，另外兩臺作為負載發(fā)生器(cPU2.8G Hz，內(nèi)存2G和CPU 3.0 GHz，內(nèi)存1G)，向服務(wù)器發(fā)送http請求，如圖1所示。

服務(wù)器采用IBM的Websphere Application Server5.1，運行在Windows 2003 Server上。測試用例采用Websphere Application Server5.1自帶的petstorel.3.1-02。Petstore是Sun公司在J2EE平臺上開發(fā)的一個樣例，是Java技術(shù)在J2EE上的藍圖程序，對于J2EE服務(wù)器測試有較強的代表性。Petstore采用MVC模式設(shè)計，由EJB層處理業(yè)務(wù)邏輯。它的數(shù)據(jù)庫是IBM的CloudScape4.0，集成在Websphere內(nèi)部。

負載發(fā)生器分別運行在Windows 2003 Server和Windows XP上。兩個負載發(fā)生器同時向服務(wù)器發(fā)送負載請求，負載模擬真實情況中大量用戶對服務(wù)器的訪問。

數(shù)據(jù)采集工具使用Websphere自帶的Tivoli性能查看器(Tivoli Performance Viewer)。它可以監(jiān)控系統(tǒng)資源的使用情況，也可以從Websphere內(nèi)部提取J2EE Server相關(guān)參數(shù)。

2 實驗方案

為了有效考察應(yīng)用服務(wù)器的性能衰退情況，特設(shè)計了如下的實驗方案：

(1)確定負載類型。根據(jù)有無狀態(tài)、有無事務(wù)分成四種請求類型，還有一種是模擬真實的客戶請求場景。

(2)確定在當(dāng)前負載情況下服務(wù)器所能處理的最大峰值：逐漸增大請求率，并記錄響應(yīng)時間。如果發(fā)現(xiàn)到某個請求率時響應(yīng)開始超時丟包且繼續(xù)增大請求率時丟包率也增大，則可認為最大峰值就是產(chǎn)生丟包之前的請求率。

(3)根據(jù)所測量的峰值從低到高分幾檔確定客戶端的請求率。

(4)在當(dāng)前請求情況下，每隔一定時間間隔(需要根據(jù)老化速度而定，如5分鐘或10分鐘。如果老化時間很長，則應(yīng)選較長的間隔，否則文件太大而且也沒有必要。反之則應(yīng)選擇較小的間隔)需要記錄的狀態(tài)包括兩大類：客戶端、服務(wù)器端。

客戶端要記錄每次請求的響應(yīng)時間，如果超時則記為-1：

服務(wù)器端要記錄反映負載情況的狀態(tài)：如CPU的任務(wù)切換次數(shù)／秒、頁面調(diào)入率、頁面調(diào)出率、系統(tǒng)調(diào)用率；反映當(dāng)前系統(tǒng)狀態(tài)的狀態(tài)：如CPU的利用率、空閑內(nèi)存空間、已用交換空間、隊列長度；反映中間件系統(tǒng)的狀態(tài)：JVM堆大小、使用內(nèi)存；Servlet容器參數(shù)包括：Servlet運行數(shù)量和用戶單位事件請求數(shù)量；EJB容器參數(shù)包括：SessionBean組件、EentityBean組件和MessageDriverBean組件而建立的其創(chuàng)建組件數(shù)量、運行組件數(shù)量、池態(tài)組件數(shù)量。

3 測試結(jié)果

測試目標(biāo)有：測試J2EE服務(wù)器中是否存在軟件老化現(xiàn)象；如果存在老化現(xiàn)象，負載對老化速度的影響有多大。

為了完成這兩個任務(wù)，設(shè)計了不同強度的負載。我們發(fā)現(xiàn)，服務(wù)器宕機直接原因是內(nèi)存耗盡，然而，宕機時間與負載強度有緊密的關(guān)系。

3.1 峰值測試

為了模擬真實場景，將用戶分為三類：瀏覽用戶(只對商品進行瀏覽，不登錄，也不購買)、登錄用戶(登錄后瀏覽商品，不購買)、購買用戶(登錄服務(wù)器后，選擇商品購買)。三類用戶是等概率隨機到來的。

服務(wù)器的峰值是指服務(wù)器在單位時間內(nèi)能夠響應(yīng)的最大用戶數(shù)量。針對三種不同的用戶分別測量其峰值?？蛻舳嗽诙涕g內(nèi)向服務(wù)器發(fā)送等強度的負載，記錄客戶端是否得到響應(yīng)及響應(yīng)時間。如果客戶端的響應(yīng)結(jié)果全部為true，則加大負載強度，直到服務(wù)器無法響應(yīng)所有請求。記錄此時的負載強度，作為服務(wù)器的峰值。

3.2 負載測試及結(jié)果分析

根據(jù)服務(wù)器的峰值，設(shè)計負載的強度。影響負載強度的兩個主要因素是單位時間內(nèi)發(fā)送請求的數(shù)量和服務(wù)的平均持續(xù)時間。

3.2.1 重負載測試

采用與峰值測試中相同的服務(wù)平均持續(xù)時間，平均負載強度為峰值的30％，高峰期的負載強度為峰值的50％。服務(wù)器在運行43小時后無法響應(yīng)客戶端請求。

如圖2所示，服務(wù)器宕機時，Java虛擬機使用內(nèi)存達到250M左右。Websphere默認Java虛擬機堆的初始大小為128M，最大值為256M。因此，可以得到結(jié)論，內(nèi)存耗盡是系統(tǒng)宕機的原因之一。

3.2.2 輕負載測試

降低單位時間內(nèi)發(fā)送請求的數(shù)量，將平均負載強度和高峰期負載強度都降低20％，服務(wù)器在運行140小時后無法響應(yīng)客

如圖3所示，服務(wù)器宕機時java虛擬機使用內(nèi)存在250M左右，與重負載情況相同，再次證實了內(nèi)存耗盡會引軟件老化。

實驗中，負載強度僅減小了20％，服務(wù)器運行時間延長了3倍多，可見，負載強度是影響軟件老化速度的主要因素。

3.2.3 延長服務(wù)平均持續(xù)時間

將服務(wù)平均持續(xù)時間延長至原來的6倍，單位時間內(nèi)發(fā)送請求的數(shù)量與輕負載測試中相同，服務(wù)器在運行8小時后無法響應(yīng)客戶端請求。

服務(wù)器宕機時內(nèi)存仍在250M左右，與上面的情況相同。

延長服務(wù)持續(xù)時間，意味著延長用戶在服務(wù)器上的停留時間。EJB容器為用戶保留占用的服務(wù)器資源，這會加快服務(wù)器的資源耗盡，因此大大縮短運行時間。

4 結(jié)束語

通過設(shè)計的實驗方案，證實了應(yīng)用服務(wù)器在長期運行的情況下存在老化現(xiàn)象，并在實驗中發(fā)現(xiàn)負載對老化速度影響明顯。但是軟件怎樣老化、老化程度如何、如何度量其老化程度、什么時候進行模塊的再生及如何再生尚有待進一步研究。