J2EE運行環境性能優化藝術之三

2019-11-18 11:47:15

字體：大中小

來源：轉載

供稿：網友

　　作者：Steven Haines；編譯：仙人掌工作室
　　
　　在前面兩篇文章中，我們界定了性能優化的意義（即提高并發用戶數量、吞吐量和可靠性），定義了優化應用和應用服務器要采用的方法。現在我們要深入應用服務器，看看有哪些因素可以調整，以及調整這些因素會對應用性能產生什么影響。具體地說，我們要深入J2EE規范，結合應用服務器的實踐知識，找出優化性能的辦法。
　　
　　一、深入了解應用服務器
　　
　　當前的大多數應用服務器遵從J2EE 1.3規范，也即它們滿足J2EE 1.3規范定義的所有需求。雖然J2EE規范只有一個，但本文提到的J2EE規范一般指一組相關的規范，因為J2EE規范涉及其他許多“應用編程接口”，而這些編程接口又有各自的規范。
　　
　　首先我們來看看J2EE 1.3規范，它的官方地址是：http://java.sun.com/j2ee/download.Html。從J2EE規范的官方網站可以看到，當前最新的J2EE規范是J2EE 1.4 Beta 2 Implementation，不過下面我們要討論的J2EE規范仍然是1.3，因為當前的應用服務器還不支持1.4。
　　
　　J2EE規范第六章定義了必須支持的組件及其版本，表一是其概況。
　　
　　表一　J2EE規范：組件及其版本
　　
　　組件　版本　
　　JDBC　2.0　
　　EnterPRise JavaBeans(EJB) 2.0　
　　Servlet　2.3　
　　JavaServer Pages (jsp)　　1.2　
　　Java Messaging Service(JMS)　1.0　
　　Java Transaction API (JTA)　　1.0　
　　JavaMail 1.2　
　　J2EE Connection Architecture (JCA)　1.0　
　　Authentication and Authorization (JAAS)　　1.0
　　
　　在J2EE規范的官方網站上可以找到上述所有技術規范的鏈接。下面我們將從性能的角度出發，看看它們各自的要點所在。
　　
　　由于每一個應用服務器都必須支持上述API集，所以我們首先可以從一個抽象的層次來觀察一個應用服務器，了解有哪些性能因素可供調整。這樣，當我們看到一個具體的應用服務器時，只要找出它是如何實現規范要求的各項技術就可以了。
　　
　　二、JDBC
　　
　　對于數據庫連接，所有的應用服務器都必須提供緩沖池機制。在應用程序中創建數據庫連接是一項開銷很大的操作，通常要耗費0.5到2秒的時間。因此，應用服務器緩沖了數據庫連接，使得不同的應用程序、同一應用程序內的多個線程能夠共享一組數據庫連接，避免每次需要數據庫連接時都從頭開始創建連接。
　　
　　通過連接池使用數據庫連接的一般過程為：當某個線程需要訪問數據庫時，它向數據庫連接池請求一個連接，然后用連接池返回的連接執行數據庫操作（例如SELECT或UPDATE、DELETE命令），操作結束后再把數據庫連接對象返回給連接池，以便其他組件使用該連接。由于J2EE應用支持多個并發用戶，連接池的規模會極大地影響應用的性能。例如，假如一個應用的90%請求都需要訪問數據庫，且應用必須支持500個用戶同時訪問，則連接池也應當預備數量龐大的連接。
　　
　　每一個應用都有不同的數據庫訪問要求，因此如何調整連接池中連接的數量也必須根據應用的具體情況確定。在優化應用性能的實踐中，必須時刻牢記的一條重要原則是：很多時候，JDBC連接池的規模往往是對應用的整體性能表現影響最大的因素之一。
　　
　　三、EJB
　　
　　EJB提供J2EE應用的中間層組件，它有四種類型：實體Bean，有狀態會話Bean，無狀態會話Bean，消息驅動的Bean。
　　
　　實體Bean和有狀態會話Bean都要維持某種類型的狀態信息。實體Bean可能代表數據庫或查詢結果的一個行????@??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????隸?????????????????????????????? ????????????????，但不管怎樣，從面向對象的角度來看實體Bean也是一個對象。另一方面，有狀態會話Bean代表的是一種臨時存儲機制，它保存的數據可以跨越單個請求的范圍，但不是永久保存的。一般地，在Web應用中，有狀態會話Bean的生命周期總是與用戶的HTTP會話相關聯的。由于有狀態會話Bean的本質是用來維持狀態，應用服務器必須為它們提供某種緩沖機制。一些簡易的應用服務器用一個單一的緩沖區來保存所有的實體Bean和有狀態會話Bean，但高級一些的應用服務器會提供更復雜、完善的緩沖機制。
　　
　　緩沖區的大小是預先設定的，它能夠保存的對象數量也有一定的上限。當出現對某個對象的請求時，系統搜索緩沖區查找當前請求的對象：假如在緩沖區中找到了對象，就直接從內存把它返回給調用者；假如找不到，則必須從永久存儲設備（例如數據庫或文件系統）讀取對象，把它放入緩沖區，再返回給調用者。假如緩沖區已滿，處理經過就要復雜多了：緩沖區治理器必須從緩沖區移出某個對象（例如，最近最少使用的對象），以便為新的對象騰出空間。用EJB的術語來說，把某個對象移出緩沖區的操作稱為鈍化（passivating），把對象裝入緩沖區的操作稱為激活（activating）。假如一個系統中鈍化操作和激活操作過于頻繁，很可能導致緩沖區治理器消耗在讀/寫持久性存儲設備上的時間遠遠超過其實際服務于請求的時間，這種現象稱為系統顛簸（thrashing）；反之，假如緩沖區治理器能夠在緩沖區中找到對象并直接把它返回給用戶，系統性能當然會大大提高，這種現象稱為緩沖區命中（cache hit）。
　　
　　調整緩沖區的時候，應當記住調整的目標是盡可能提高緩沖區命中的次數，盡可能減少系統顛簸現象。要達到該目標，首先必須深入、全面地理解應用的對象模型以及每一個對象的使用情況。
　　
　　無狀態會話Bean和消息驅動的Bean不能維持任何狀態信息。假如一個進程在第一次操作中請求一個無狀態會話Bean，在另一次操作中又請求同一類型的無狀態會話Bean，系統不保證該進程會收到同一個Bean實例。這一機制帶來很多方便，因為Bean治理器不必治理業務進程及其所屬Bean的交互過程，它只要在請求出現時提供適當類型的Bean實例就可以了。
　　
　　為了給來自業務過程的請求提供流暢的服務，Bean緩沖池必須足夠大，否則的話，業務過程可能要等待一段時間才能獲得Bean實例來完成其操作。假如緩沖池太小，有可能會出現許多業務過程等待Bean實例的情形；假如緩沖池太大，它會占用超出其實際需求的系統資源。
　　
　　無狀態會話Bean和消息驅動的Bean還有一個很有用的特點，應用服務器可以預先裝入它們，而不必等到請求出現時才把它們裝入緩沖池。因此，對于無狀態會話Bean和消息驅動的Bean來說，兩個很重要的性能選項就是緩沖池的大小和預先裝入緩沖池的Bean的數量。
　　
　　四、Servlet和JSP
　　
　　Servlet和JSP各有獨立的規范，但在運行時裝入內存的實際上只有Servlet，因為JSP會被自動轉換成Servlet。Servlet和JSP本身也不能在多個請求之間維持狀態信息，因此應用服務器可以方便地把它們放入緩沖池，就性能而言，可供調整的兩個最重要的選項也是緩沖池的大小和預先裝入緩沖池的Servlet的數量。
　　
　　由于JSP在裝入內存之前要先經過轉換和編譯的工序，大多數應用服務器支持一種在部署之前預先編譯JSP的機制，避免JSP頁面第一次被調用時可能會出現的延遲。
　　
　　Servlet（以及JSP）支持四種不同的數據保存范圍（或內存區域）：
　　
　　◆ Page：保存在這里的數據只在單個頁面范圍有效。
　　
　　◆ Request：保存在這里的數據在單個請求的范圍內有效（在返回應答給調用者之前，數據在Servlet、JSP頁面之間傳遞）。
　　
　　◆ session：保存在這里的數據在用戶會話期間一直有效（數據的有效范圍跨越多個請求，直至請求超時或數據被顯式地清除）。
　　
　　◆ application：保存在這里的數據是全局性數據，對應用的所有Servlet和JSP都有效，除非數據被顯式地清除，或者Servlet容器重新啟動。
　　
　　在Servlet/JSP編程中，數據存儲位置的選擇是非常重要的，它將極大地影響應用占用的內存總量。四種范圍之中，尤以session范圍對內存占用的影響最大：保存在session范圍中的數據將按照并發用戶數量的倍數占用內存。例如，假如應用在session范圍中保存了10 KB數據，有500用戶在運行應用，那么這些數據實際占用的內存將達到5 MB。僅僅占用5 MB內存當然不會使應用出現資源緊張的情形，但考慮一下，假設原來的500個用戶離開了，又來了另外500個用戶，這時內存占用就將達到10 MB，這種情形還有可能進一步發展下去，導致內存耗用????@??????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????隸?????????????????????????????? ????????????????越來越大。
　　
　　HTTP是一種無狀態的協議，也就是說，當客戶程序連接到服務器，發出一個請求，服務器作出應答，連接就結束了。應用服務器不知道用戶實際離開網站和結束會話的時間，它使用的是一種超時機制，也就是定義一個時間，假如用戶在該時間范圍內沒有再次向服務器發送請求，則該會話就被清除。會話超時時間的設置依靠于應用、用戶和要用多少內存來保留用戶的會話，既不能使動作慢的用戶頻繁地重新建立會話，又要避免超時時間設置得過長，白白耗費內存來保留那些實際上不再需要的會話。
　　
　　五、Java消息服務
　　
　　JMS服務器為應用程序執行異步操作帶來了方便。隨著EJB 2.0的出現，EJB家族中增加了一種消息驅動的Bean——這是一種無狀態的Bean，代表著由JMS消息初始化的業務過程。一個程序把消息放入JMS的目標

上一篇：Java初學者應該搞懂的六個問題

下一篇：理解類加載器：J2EE 環境下的 log4j