J2EE應用服務器性能優化方法研究

金思軼

（杭州師范大學錢江學院 計算機科學與技術專業，浙江 杭州 310012）

1 引言

J2EE是一種利用Java 2平臺來簡化企業解決方案的開發、部署和管理相關的復雜問題的體系結構。不同的J2EE應用服務器都有對應的具體的參數可供調整，一些J2EE應用服務器的供應商都提供一些應用指南，然而關于應用服務器資源如何優化的相關研究則很少。

2 影響J2EE應用服務器性能的關鍵因素

J2EE應用服務器是多模塊、多線程、分布式的程序，因此影響性能的因素是多方面的，而且各因素間是相互影響，綜合關聯的。

2.1 Java虛擬機堆設置

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

2.2 處理線程池大小

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

2.3 數據庫連接配置

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

3 J2EE應用服務器性能評測標準

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

性能標準依賴于所測試的應用程序類型。基于J2EE平臺的應用程序一般分為兩個基本類別:交互式的應用程序和批處理或后端應用程序。

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

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

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

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

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

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

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

每種度量標準都需要結合一個規定的用戶負載，比如性能評測標準為400個用戶負載最多3秒的最大響應時間。

4 應用服務器資源優化方法

4.1 基于策略方法

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

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

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

4.2 基于經驗方法

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

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

該方法之所以有效，是因為同一組參數多次測試，性能情況都差不多;因此不同參數獲得不同性能，可以認為是參數配置而引起的，從而可以發現問題所在和選取有效的參數配置。但這種測試方法需要時間長，試驗次數多。因此為減少測試的次數，加快尋優的步伐，可采用優化抽樣、搜索算法與少量測試結合的方法尋找最佳配置集。總之經驗方法為應用服務器參數靜態優化提供較好的途徑，然而此方法不能解決應用服務器在線動態調優。

4.3 基于反饋控制方法

在反饋驅動的方法中，OAA框架基于收斂或背離于管理員所定義單個或多個性能度量值的目標，對控制柄反復迭代調整。例如:如果OAA框架正設法為J2EE應用服務器維持某個管理員指定的響應時間，對系統當前的響應時間與一些目標響應時間比較的前提下，OAA框架必須對調節柄反復控制。基于反饋的解決方案中，使用了一系列古典的控制理論技術(如簡化啟發式探試學和估計技術)確定特定的控制柄集合。OAA框架評估調優后的效果，確定是否需要其他的調整。由于關于性能度量的結果被反饋到調整器，確定下一步的調整策略;所以觀察和調整的動作構成了反饋循環。

[1]黃濤，一個面向QoS的Web應用服務器，軟件學報，2004,

[2]謝希仁，計算機網絡，大連理工大學出版社，2003