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

金思軼

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

1 引言

J2EE是一種利用Java 2平臺(tái)來簡(jiǎn)化企業(yè)解決方案的開發(fā)、部署和管理相關(guān)的復(fù)雜問題的體系結(jié)構(gòu)。不同的J2EE應(yīng)用服務(wù)器都有對(duì)應(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虛擬機(jī)堆設(shè)置

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

2.2 處理線程池大小

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4.1 基于策略方法

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

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

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

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

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

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

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

4.3 基于反饋控制方法

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

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

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