J2EE應(yīng)用服務(wù)器性能優(yōu)化方法研究

金思軼

（杭州師范大學(xué)錢江學(xué)院 計算機科學(xué)與技術(shù)專業(yè)，浙江 杭州 310012）

1 引言

J2EE是一種利用Java 2平臺來簡化企業(yè)解決方案的開發(fā)、部署和管理相關(guān)的復(fù)雜問題的體系結(jié)構(gòu)。不同的J2EE應(yīng)用服務(wù)器都有對應(yīng)的具體的參數(shù)可供調(diào)整，一些J2EE應(yīng)用服務(wù)器的供應(yīng)商都提供一些應(yīng)用指南，然而關(guān)于應(yīng)用服務(wù)器資源如何優(yōu)化的相關(guān)研究則很少。

2 影響J2EE應(yīng)用服務(wù)器性能的關(guān)鍵因素

J2EE應(yīng)用服務(wù)器是多模塊、多線程、分布式的程序，因此影響性能的因素是多方面的，而且各因素間是相互影響，綜合關(guān)聯(lián)的。

2.1 Java虛擬機堆設(shè)置

任何Java應(yīng)用的性能調(diào)整基礎(chǔ)都涉及到堆的大小和垃圾回收設(shè)置。堆可分為三代，年輕的(新的)、年老的和持久的。當(dāng)配置最大堆大小時可參考下面一些指導(dǎo):最大大小應(yīng)小于物理內(nèi)存，避免虛存的頁面調(diào)度。在負載測試時進行優(yōu)化，需要減去其他進程使用的內(nèi)存。注意不要將最大堆大小設(shè)置得過大。堆越大，內(nèi)存中保存的對象越多。內(nèi)存中對象越多，回收過程時間越長。配置初始堆大小的一般性策略包括:將初始大小設(shè)置為最大堆大小的1/4到1/2，對于年輕一代堆大小，Sun推薦是設(shè)置為最大堆大小的1/3。

2.2 處理線程池大小

由于應(yīng)用服務(wù)器能夠同時為多個并發(fā)的用戶請求提供服務(wù)，而創(chuàng)建線程又是一項昂貴的操作，所以應(yīng)用服務(wù)器必須通過一個線程池來處理各種請求。一些應(yīng)用服務(wù)器把這個線程池一分為二:其中一個用來處理進入的請求，把請求放入隊列;另一個從隊列獲取線程，然后執(zhí)行調(diào)用者要求執(zhí)行的處理任務(wù)。不管具體的實現(xiàn)方式是哪一種，線程池的大小限制了應(yīng)用服務(wù)器的工作量，所以必須找出一個最佳的平衡點-如果超越這個平衡點，則線程的上下文切換(將CPU依次分配給各個線程)將產(chǎn)生大量開銷，從而影響性能。很多應(yīng)用服務(wù)器允許為特定的任務(wù)或應(yīng)用配置不同大小的線程池。通常需要增加這些線程池的大小以滿足應(yīng)用負載的需要。線程池的設(shè)置不能過小，也不能過大，這是因為設(shè)置過大會增加上下文交換的次數(shù)，從而降低應(yīng)用的性能。線程池的大小通常應(yīng)該能最大利用機器上的CPU，同時又不能使CPU過載。

2.3 數(shù)據(jù)庫連接配置

對于數(shù)據(jù)庫連接，所有的應(yīng)用服務(wù)器都提供緩沖池機制。在應(yīng)用程序中創(chuàng)建數(shù)據(jù)庫連接是一項開銷很大的操作，通常要耗費0.5到2秒的時間。因此應(yīng)用服務(wù)器緩沖了數(shù)據(jù)庫連接，使得不同的應(yīng)用程序、同一應(yīng)用程序內(nèi)的多個線程能夠共享一組數(shù)據(jù)庫連接，避免每次需要數(shù)據(jù)庫連接時都從頭開始創(chuàng)建連接。通過連接池使用數(shù)據(jù)庫連接的一般的過程為:當(dāng)某個線程需要訪問數(shù)據(jù)庫時，它向數(shù)據(jù)庫連接池請求一個連接，然后用連接池返回的連接執(zhí)行數(shù)據(jù)庫操作 (例如SELECT或UPDATE,DELETE命令)，操作結(jié)束后再把數(shù)據(jù)庫連接對象返回給連接池，以便其他組件使用該連接。

3 J2EE應(yīng)用服務(wù)器性能評測標(biāo)準(zhǔn)

性能測試的原理主要是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統(tǒng)的各項性能指標(biāo)進行測試。通過模擬上千萬用戶的實施并發(fā)負載及實時性能監(jiān)測的方式來確認和查找問題。

性能標(biāo)準(zhǔn)依賴于所測試的應(yīng)用程序類型。基于J2EE平臺的應(yīng)用程序一般分為兩個基本類別:交互式的應(yīng)用程序和批處理或后端應(yīng)用程序。

3.1 對于交互式應(yīng)用程序，即終端用戶與應(yīng)用程序同步交互，性能一般是通過大小和規(guī)劃問題的容量來定義，性能評測標(biāo)準(zhǔn)可以是一個最大可接受的響應(yīng)時間，這就是在得到應(yīng)用程序響應(yīng)之前客戶愿意等待的最大時間數(shù)量。

3.2 對于批處理或后端應(yīng)用程序，即不需要直接與終端用戶交互，性能評測標(biāo)準(zhǔn)是每秒事務(wù)處理最小可接受的吞吐量。事務(wù)處理在具體的場合定義可能有所不同。比如對于Servlet，事務(wù)處理可能為一個請求;而對JMS，吞吐量可能就是消息。性能標(biāo)準(zhǔn)的定義分別如下:

響應(yīng)時間RT(Response Time):客戶端從發(fā)送請求的那一刻起到收到應(yīng)用程序響應(yīng)的最后一個字節(jié)時而不得不等待的時間長度。

平均響應(yīng)時間ART(Average Response Time):某個特定請求所有用戶響應(yīng)時間的算術(shù)平均。

最大平均響應(yīng)時間MART (Maximum Average Response Time):一個測試腳本中所有單獨的平均響應(yīng)時間中最高的值。

吞吐量:每秒處理的事務(wù)數(shù)量(Transactions Per Second,RPS)。

拒絕率(Reject Rate):為了保證已連接客戶的性能，而不得不能提供服務(wù)的客戶數(shù)目。

每種度量標(biāo)準(zhǔn)都需要結(jié)合一個規(guī)定的用戶負載，比如性能評測標(biāo)準(zhǔn)為400個用戶負載最多3秒的最大響應(yīng)時間。

4 應(yīng)用服務(wù)器資源優(yōu)化方法

4.1 基于策略方法

系統(tǒng)管理員編寫策略，如:事件一條件一動作(ECA)的規(guī)則集合。當(dāng)一些前置條件被滿足時，就會觸發(fā)這些規(guī)則(通常一個或多個系統(tǒng)的可觀察的變化超出管理員定義的閡值)?；谝?guī)則的方法是建立在Hewitt模式導(dǎo)向范式。模式非常類似事件一條件定義。在不同的系統(tǒng)狀態(tài)下，規(guī)則集作為“打包的處方”決定怎樣調(diào)用正確的動作。運行時，管理模塊只調(diào)用合適的規(guī)則基于事件和系統(tǒng)條件。只有擁有多年豐富經(jīng)驗的專家如系統(tǒng)架構(gòu)設(shè)計者和管理者才能編寫管理規(guī)則。然而隨著系統(tǒng)變得更復(fù)雜，即使專家也會遇到以下類型的問題，設(shè)計強魯棒性的自動管理框架相當(dāng)困難的。

復(fù)雜性:編寫規(guī)則集合是非常困難的工作。原因如下:(1)從大量可能的觀察集合中難以選擇適宜的系統(tǒng)參數(shù)配置。(2)在考慮各類系統(tǒng)變量的交互后難以確定恰當(dāng)?shù)拈u值。(3)從大量的競爭選擇選項中難以選擇詳細而清晰的動作。

脆弱性:系統(tǒng)廠商無法為自身的產(chǎn)品提供預(yù)先打包的ECA規(guī)則集。規(guī)則集與變化的系統(tǒng)配置、用戶工作負載、商業(yè)約束間的關(guān)系是非常脆弱的。更新和操作規(guī)則語意不是容易的事。預(yù)先構(gòu)思各種運行場景及對應(yīng)的規(guī)則是有難度的。

4.2 基于經(jīng)驗方法

傳統(tǒng)上應(yīng)用服務(wù)器的性能調(diào)優(yōu)沒有更好的辦法，更多的時候都是依靠配置人員的自覺、經(jīng)驗和實踐來決定資源和參數(shù)的配置。為此一些商家還專門出了對應(yīng)的白皮書，給出推薦的參數(shù)設(shè)置值。經(jīng)驗方法是通過一系列的測試標(biāo)識不同配置參數(shù)集的情況下的系統(tǒng)性能瓶頸和系統(tǒng)特性。測試是一個需要反復(fù)進行的過程:第一次只能從一個看起來似乎不錯的配置開始，一般參數(shù)的取值可使用系統(tǒng)默認值，或由軟件供應(yīng)商提供的指導(dǎo)，然后測試、分析系統(tǒng)，再根據(jù)測試結(jié)果調(diào)整、配置系統(tǒng)，具體尋找好的配置的步驟如下:

為每個參數(shù)選擇分配合理的區(qū)間，如:JVM最大堆棧區(qū)間，我們推薦的范圍是256-512M；每個參數(shù)的具體值從參數(shù)的區(qū)間隨機生成；使用從步驟2中得到值部署應(yīng)用；對應(yīng)用服務(wù)器進行負載測試，并度量其性能數(shù)據(jù)，如:響應(yīng)時間和吞吐量；如果需要，重復(fù)上述步驟。

該方法之所以有效，是因為同一組參數(shù)多次測試，性能情況都差不多;因此不同參數(shù)獲得不同性能，可以認為是參數(shù)配置而引起的，從而可以發(fā)現(xiàn)問題所在和選取有效的參數(shù)配置。但這種測試方法需要時間長，試驗次數(shù)多。因此為減少測試的次數(shù)，加快尋優(yōu)的步伐，可采用優(yōu)化抽樣、搜索算法與少量測試結(jié)合的方法尋找最佳配置集?？傊?jīng)驗方法為應(yīng)用服務(wù)器參數(shù)靜態(tài)優(yōu)化提供較好的途徑，然而此方法不能解決應(yīng)用服務(wù)器在線動態(tài)調(diào)優(yōu)。

4.3 基于反饋控制方法

在反饋驅(qū)動的方法中，OAA框架基于收斂或背離于管理員所定義單個或多個性能度量值的目標(biāo)，對控制柄反復(fù)迭代調(diào)整。例如:如果OAA框架正設(shè)法為J2EE應(yīng)用服務(wù)器維持某個管理員指定的響應(yīng)時間，對系統(tǒng)當(dāng)前的響應(yīng)時間與一些目標(biāo)響應(yīng)時間比較的前提下，OAA框架必須對調(diào)節(jié)柄反復(fù)控制?；诜答伒慕鉀Q方案中，使用了一系列古典的控制理論技術(shù)(如簡化啟發(fā)式探試學(xué)和估計技術(shù))確定特定的控制柄集合。OAA框架評估調(diào)優(yōu)后的效果，確定是否需要其他的調(diào)整。由于關(guān)于性能度量的結(jié)果被反饋到調(diào)整器，確定下一步的調(diào)整策略;所以觀察和調(diào)整的動作構(gòu)成了反饋循環(huán)。

[1]黃濤，一個面向QoS的Web應(yīng)用服務(wù)器，軟件學(xué)報，2004,

[2]謝希仁，計算機網(wǎng)絡(luò)，大連理工大學(xué)出版社，2003