weblogic優化

摘要：

　　隨着近來J2EE軟件廣泛地應用於各行各業，系統調優也越來越引起軟件開發者和應用服務器提供商的重視。而對於最終客戶來說，在一個高效、 穩定地實現他們的業務需求已經是他們的基本要求。所以J2EE調優顯得非常重要，而BEA WebLogic Server是業界領先的應用服務器，BEA WebLogic平臺下的J2EE調優也就尤爲重要,她將爲我們提供普遍的J2EE調優方案。最近網絡、雜誌上的J2EE調優文章層出不窮。本人也將自己 平時工作中的一些經驗積累分享給大家，拋磚引玉。

目錄

前 言
第一章 應用程序調優
1.1.1 通用代碼調優
1.1.2 減小沒有必要的操作
1.1.3 使用合適的類型
1.1.4 儘量使用pool,buffer和cache
1.2 JDBC代碼調優
1.2.1 嚴格資源使用
1.2.2 實用技巧
1.2.3 優化SQL語句
1.3 Web代碼調優
1.3.1 HttpSession的使用
1.3.2 JSP代碼調優
1.3.3 Servlet代碼調優
1.4 JMS代碼調優
1.4.1 注意必要的事項，避免使用不必要的特徵
1.4.2 消息類型的選擇
1.4.3 確認方式的選擇和JMS事務
1.5 EJB代碼調優
1.5.1 有效使用設計模式
1.5.2 使用EJB和WebLogic的特性
1.5.3 緩存資源
1.5.4 如何選擇和使用Entity Bean
1.5.5 其他的一些小技巧
第二章 應用服務器調優
2.1 JVM調優
2.1.1 垃圾收集和堆大小
2.1.2 jRockit調優
2.2 Server調優
2.2.1 儘量使用本地I/O庫
2.2.2 調整默認執行線程數
2.2.3 調整連接參數
2.2.4 創建新的執行隊列
2.3 JDBC調優
2.3.1 調整連接池配置
2.4 WEB調優
2.4.1 調整WEB應用描述符
2.5 JMS調優
2.6 EJB調優
2.6.1 調整pool和cache
2.6.2 優化事務隔離級別和事務屬性
2.6.3 其他一些小技巧
第三章 數據庫調優
3.1.1 Oracle性能優化
3.1.2 Oracle的其他調整
第四章 操作系統調優
4.1 操作系統調整
4.1.1 HP-UX
4.1.2 Solaris
4.1.3 AIX
4.1.4 Linux
4.1.5 Windows
第五章 性能監控和性能分析
5.1 性能瓶頸
5.2 操作系統監控
5.3 數據庫監控
5.4 WebLogic監控
5.4.1 JVM監控
5.4.2 Console監控
5.4.3 實用工具分析
5.5 應用程序分析
總結
參考文獻
關於作者

前 言 (目錄)

　　隨着近來J2EE軟件廣泛地應用於各行各業，系統調優也越來越引起軟件開發者和應用服務器提供商的重視。而對於最終客戶來說，在一個高效、 穩定地實現他們的業務需求已經是他們的基本要求。所以J2EE調優顯得非常重要，而BEA WebLogic Server是業界領先的應用服務器，BEA WebLogic平臺下的J2EE調優也就尤爲重要,她將爲我們提供普遍的J2EE調優方案。最近網絡、雜誌上的J2EE調優文章層出不窮。本人也將自己 平時工作中的一些經驗積累分享給大家，拋磚引玉。

　　本文從J2EE應用架構（下圖）來分別剖析系統調優，首先我們一般會從應用程序出 發，去審覈代碼，做到代碼級的優化，然後再調整應用服務器(BEA WebLogic8.1)和數據庫 (Oracle9i)的參數，最後當然是調整操作系統和網絡的性能(包括硬件升級)。誠然,在我遇到的很多項目中,都是出現了性能問題後纔想到調優,而且 一般都是先進行系統參數調整,實在解決不了纔會對代碼進行檢查.實際上,我們應當將代碼級的調優放在應用設計時來做,測試生產時修改代碼將是一件極其痛苦 的事情。

WebLogic平臺J2EE應用架構

第一章 應用程序調優(目錄)
1.1.1 通用代碼調優

1.1.2 減小沒有必要的操作
　 　對象的創建是個很昂貴的工作,所以我們應當儘量減少對象的創建,在需要的時候聲明它,初 始化它,不要重複初始化一個對象,儘量能做到再使用,而用完後置null有利於垃圾收集。讓類實現Cloneable接口,同時採用工廠模式,將減少類的 創建,每次都是通過clone()方法來獲得對象。另外使用接口也能減少類的創建。對於成員變量的初始化也應儘量避免, 特別是在一個類派生另一個類時。

　 　異常拋出對性能不利。拋出異常首先要創建一個新的對象。Throwable接口的構造函數調用名爲, fillInStackTrace()的本地（Native）方法，fillInStackTrace()方法檢查堆棧，收集調用跟蹤信息。只要有異常被 拋出，VM就必須調整調用堆棧，因爲在處理過程中創建了一個新的對象。 異常只能用於錯誤處理，不應該用來控制程序流程。

　　此外, 建議關閉Debug輸出,儘量少用串行化、同步操作和耗時昂貴的服務(如Date())。

1.1.3 使用合適的類型
　　當原始類型不能滿足我們要求時,使用複雜類型。String和StringBuffer的區別自不必說了,是我們使用最多的類型,在涉及到字符運算時,強烈建議使用StringBuffer。在做String匹配時使用intern()代替equal()。

　　帶有final修飾符的類是不可派生的, 如果指定一個類爲final，則該類所有的方法都是final。

　　Java編譯器會尋找機會內聯所有的final方法,這將能夠使性能平均提高50%。類的屬性和方式使用final或者static修飾符也是有好處的。

　　調用方法時傳遞的參數以及在調用中創建的臨時變量都保存在棧（Stack）中，速度較快。所以儘量使用局部變量。

　　ArrayList和Vector,HashMap和Hashtable是我們經常用到的類,前者不支持同步,後者支持同步,前者性能更好,大多數情況下選擇前者。

1.1.4 儘量使用pool,buffer和cache
　　使用pool、buffer和cache能大大提高系統的性能,這在J2EE的大部分技術中都是適用的。

　 　在WebLogic中就大量使用了池:JDBC Connection Pool、Socket Pool、Object Pool和Thread Pool。I/O操作中,buffer是必須的,特別是對大文件的操作,不然容易造成內存溢出。字節操作最快,所以儘可能採用 write(byte[])，Buffered FileOutputStream比Buffered FileWriter要快,因爲FileWriter需要Unicode到Byte的轉換。

　　而後面講到的JDBC、JSP、EJB和JMS我們都非常建議使用buffer和cache。爲HttpServletResponse設置buffersize,使用wl-cache,緩存在JNDI樹上獲取的對象等等。

　　此外,使用JDK 1.4的非阻塞I/O對性能也有很大提高。

1.2 JDBC代碼調優
1.2.1 嚴格資源使用
　 　JDBC代碼調優最大的原則就是使用WebLogic的連接池,而不是自己直連數據庫。在我接觸的很多自己實現連接池的項目中,大部分遇到死鎖和連接泄 漏的問題，最後得不得修改代碼。而WebLogic提供了功能強大，性能良好的數據庫連接池，我們要做的只是封裝一個連接管理類，從JNDI樹上獲取數據 源並緩存，得到連接，並提供一系列關閉數據庫資源的方法。

　　對任何資源使用的原則是用完即關，不管是數據庫資源、上下文環境，還是文 件。數據庫資源的泄漏極易造成內存泄漏，乃至系統崩潰。在使用完數據庫資源後依次關閉ResultSet，Statement和Connection，而 在一個數據庫連接多次進行數據庫操作時要特別注意ResultSet和Statement依次關閉。

try{
　　//open connection
　　pstmt =conn.prepareStatement(strSql1);
　　pstmt.executeUpdate();
　　pstmt.close();
　　pstmt =conn.prepareStatement(strSql2);
　　rs=pstmt.executeQuery();
　　while (rs.next()){
　　//process
　}
rs.close();
pstmt.close();
　}catch(Exception e){
　　//close rs,psmt,con
}finally{
　　//close rs,psmt,con
}

1.2.2 實用技巧
　 　在JDBC操作中還有一些小的技巧跟大家分享：由於獲取連接時默認自動提交方式，使用connection.setAutoCommit(false) 關閉自動提交，使用PreparedStatement,批量更新,業務複雜或者大數據量操作時使用存儲過程，儘量使用RowSet，此外設置記錄集讀取 緩存FetchSize和設置記錄集讀取方向FetchDirection對性能也有一定的提高。

1.2.3 優化SQL語句
　 　SQL語句的優化牽涉到很多數據庫的知識，需要與索引配合，因此需要DBA對代碼中的SQL進行檢查測試。常見的，select *不提倡使用，效率極差，建議顯式獲取列，即使是所有字段也應羅列，而取總數時使用count(*),爲提高cache的命中率，儘量做到SQL重用。對 於大數據量的查詢，可以充分利用Oracle數據庫的特性，每次取出m-n行的數據，實現分頁查詢。另外，提高性能的好選擇可能就是把所有的字符數據都保 存爲Unicode，Java以Unicode形式處理所有數據，因此，數據庫驅動程序不必再執行轉換過程。

1.3 Web代碼調優
1.3.1 HttpSession的使用
　　應用服務器保存很多會話時，容易造成內存不足，所以儘量減少session的使用，放置session
裏的對象不應該是大對象，最好是簡單小對象，實現串行化接口。當會話不再需要時，應當及時調用invalidate()方法清除會話。而當某個變量不需要時，及時調用removeAttribute()方法清除變量。請勿將EJB對象放置在session中。

1.3.2 JSP代碼調優
　 　目前，在JSP頁面中引入外部資源的方法主要有兩種：include指令，以及include動作。 include指令：例如<%@ include file="copyright.html" %>，該指令在編譯時引入指定的資源。在編譯之前，帶有include指令的頁面和指定的資源被合併成一個文件。被引用的外部資源在編譯時就確定， 比運行時才確定資源更高效。
include動作：例如<jsp:include page="copyright.jsp" />。該動作引入指定頁面執行後生成的結果。由於它在運行時完成，因此對輸出結果的控制更加靈活。但是，只有當被引用的內容頻繁地改變時，或者在對 主頁面的請求沒有出現之前，被引用的頁面無法確定時，使用include動作才合算。

　　對於那些無需跟蹤會話狀態的jsp，關閉自動 創建的會話可以節省一些資源。使用如下page指令： <%@ page session="false"%> ;儘量不要將JSP頁面定義爲單線程，應設置爲<%@page isThreadSafe=”true”%>;在JSP頁面最好使用輸出緩存功能，如: <%@page buffer="32kb"%>;儘量用wl:cache定製標記來緩存靜態或相對靜態的內容，緩存jsp:include操作的結果能顯著提高應 用程序的運行性能。

1.3.3 Servlet代碼調優
　 　Servlet代碼調優比較簡單：在Servlet之間跳轉時，forward比sendRedirect更有效；設置 HttpServletResponse 緩衝區，如：response.setBufferSize(20000);在init()方法裏緩存靜態數據，而在destroy()中釋放它；建議在 Servlet裏使用ServletOutputStream輸出圖片等對象；避免在Servlet和Jsp中定界事務等。

1.4 JMS代碼調優
1.4.1 注意必要的事項，避免使用不必要的特徵
　 　JMS提供了強有力的消息處理機制，但是爲了最大限度的提高JMS系統的性能，應避免使用不需要使用的特徵，同時也要注意必要的事項。比如：儘量使用接 收程序能直接使用的最簡單、最小的消息類型；消息選擇器要儘可能簡單(最好不使用)，儘量不要使用複雜的操作符，如like、in或者between等, 使用字符串數據類型的速度最慢;務必爲特定的應用程序定義特定的JMS連接工廠，並且禁用默認的JMS連接工廠；不要在javax.*與 weblogic.*的名字空間中使用JNDI名稱；儘量使用異步消費者，線程不必封鎖以等待消息的到達;使用完JNDI樹上的資源後注意關閉。

1.4.2 消息類型的選擇
　 　標準JMS提供了五種消息類型，而TextMessage應用最爲普遍, 當發送的消息是幾種原始數據類型的集合體時，最好使用MapMessage消息類型，而不要使用ObjectMessage，以便減少不同系統間的耦合。 此外消息是否使用壓縮要慎重考慮，壓縮未必能減少消息大小。如果生產者、消費者和目的地並置在同一WebLogic Server內部，通常不使用壓縮。WebLogic特有的XMLMessage能爲運行於消息主體之上的消息選擇器提供內嵌式支持，而且易於數據交換。 因此，建議應用程序之間傳送消息使用XML消息格式，而應用程序內部間傳送消息使用二進制消息格式。

1.4.3 確認方式的選擇和JMS事務
　 　使用事務性會話時,儘量使用恰當的消息確認方式:如果需求允許,使用NO_ACKKNOWLEDGE;非持久的訂閱者使用 DUPS_OK_ACKNOWLEDGE或者MULTICAST_NO_ACKNOWLEDGE。而使用JTA的UserTransaction，確認方 式將被忽略。在使用JMS事務時，無效的消息會導致事務的回滾，以致消息重發這樣的死循環。此時，可以將無效消息發送到錯誤消息隊列，並提交JMS事務， 這將確保消息不會再次傳遞。

1.5 EJB代碼調優
1.5.1 有效使用設計模式
　 　GoF 的《設計模式》爲我們實現高性能、易擴展的J2EE應用提供理論保障和技術支持。而EJB作爲J2EE的核心組件和技術，善用設計模式對系統性能影響很 大。Service Locator 和Value Object 已爲我們所熟悉，Floyd Marinescu的《EJB Design Patterns》中的Session Fa?ade、Message Fa?ade、EJB Command和Data Transfer Object等設計模式更是爲我們提供設計典範：緩存對EJBHome的訪問；使用門面模式，不暴露Entity Bean，用Session Bean封裝Entity Bean；如果可以異步處理，則用MDB代替Session Bean；封裝業務邏輯在輕量級JavaBean中；使用值對象等簡單對象傳遞數據;不直接使用get/set方法操作Entity Bean。當然過度使用模式或者牽強套用模式也是不提倡的，總的原則就是減少網絡流量，改進事務管理。

1.5.2 使用EJB和WebLogic的特性
　 　使用EJB和WebLogic的新特性往往能提高性能。與EJB2.0特性相關的技巧有：一個Application中使用本地接口，對於Entity Bean肯定使用本地接口，避免遠程調用的開銷；使用CMP管理關係，而不是BMP，EJB2.0中CMP的性能大大改善，性能和移植性都優於BMP；使 用ejbSelect進行內部查詢；使用home方法進行外部查詢和批處理; 數據庫驅動級聯刪除等。

　　與WebLogic特性相關的 技巧有:使用自動生成主鍵,WebLogic爲Oracle和Sqlserver兩種數據庫的CMP提供了自動生成主鍵功能,節約了Entity Bean產生主鍵的時間,同時設key-cache-size不小於100;WebLogic管理事務性能更好,使用容器管理,而不是Bean管理事 務;WebLogic提供了爲CMP動態查詢和批量插入功能,對性能也有很大幫助。

1.5.3 緩存資源
　 　對SLSB或者MDB來說,使用setMesssageDrivenContext()或者ejbCreate()方法緩存特定資源,在 ejbRemove()方法裏釋放; 對SLSB或者MDB來說,使用setSessionContext()或者ejbCreate()方法緩存特定資源,在ejbRemove()方法裏釋 放;對Entity Bean來說,使用setEntityContext ()方法緩存特定資源,在unSetEntityContext ()方法裏釋放。

1.5.4 如何選擇和使用Entity Bean
　　1. 在設計EJB時，要適當考慮EJB的粒度, 細粒度的EJB在事務管理和資源管理的開銷太大,儘量創建粗粒度的 EJB , 不要太粗，粗到能滿足實際需求就可以;

　　2. Entity Bean不是唯一方式,如果只有一個很小的數據子集被經常改變，建議採用JDO;

　　3. 在操作大數據量的時候,直接採用JDBC比Entity Bean更有效;

　　4. 避免採用返回很大數據組的finder方法,如 FindAll() 方法，因爲它的實現代價太大;

　　5. 考慮設置域組field groups,減少沒有必要並昂貴的屬性加載,如BLOB;

　　6. 對於EJB1.1或者BMP,可以設置is-modified-method-name屬性,根據isModified()的值來判斷是否調用ejbStore()等方法,減少沒有必要運算;

　　7. 避免連接多個表創建BMP,可以使用視圖,存儲過程或者O/R Mapping等方式。

1.5.5 其他的一些小技巧
　　1. 考慮使用 javax.ejb.SessionSynchronization 接口,提供在Rollback之後恢復數據的方法: afterBegin(), beforeCompletion(), afterCompletion();
　　2. 使用完SFSB之後，調用remove()方法釋放實例;
　　3. 假如你不需要EJB服務的時候,建議使用普通Java類;
　　4. 避免EJB之間相互調用;
　　5. 使用多讀模式。

第二章 應用服務器調優(目錄)
2.1 JVM調優
2.1.1 垃圾收集和堆大小
　 　垃圾收集(GC)是指JVM釋放Java堆中不再使用的對象所佔用的內存的過程,而Java堆(Heap)是指Java應用程序對象生存的空間。堆大小 決定了GC的頻度和時間。堆越大,GC頻度低,速度慢。堆越小,GC頻度高,速度快。所以GC和堆大小是一組矛盾。爲了獲取理想的Heap堆大小,需要使 用-verbosegc參數(Sun jdk: -Xloggc:<file>)以打開詳細的GC輸出。分析GC的頻度和時間,結合應用最大負載所需內存情況,得出堆的大小。
通常情 況下,我們建議使用可用內存(除操作系統和其他應用程序佔用之外的內存)70-80%,爲避免堆大小調整引起的開銷,設置內存堆的最小值等於最大值 即:-Xms=-Xmx。而爲了防止內存溢出,建議在生產環境堆大小至少爲256M(Platform至少512M),實際環境中512M~1G左右性能 最佳,2G以上是不可取的,在調整內存時可能需要調整核心參數進程的允許最大內存數。對於sun和hp的jvm,永久域太小(默認4M)也可能造成內存溢 出,應增加參-XX:MaxPermSize=128m。建議設置臨時域-Xmn的大小爲-Xmx的1/4~1/3, SurvivorRatio爲8。

　 　爲了獲得更好的性能,建議在啓動文件設置WebLogic爲產品模式,此時sun和hp jvm JIT引擎爲-server,默認情況下打開JIT編譯模式對性能也有幫助。調整Chunk Size和Chunk Pool Size也可能對系統的吞吐量有提高。此外還需關閉顯示GC: -XX:+DisableExplicitGC。

　　當然在Intel平臺上使用jRockit（使用參數-jrockit）無疑大大提高WebLogic性能。

2.1.2 jRockit調優
　 　jRockit支持四種垃圾收集器：分代複製收集器、單空間併發收集器、分代併發收集器和並行收集器。默認狀態下，JRockit使用分代併發收集器。 要改變收集器，可使用-Xgc:<gc-name>,對應四個收集器分其他爲gencopy, singlecom, gencon以及parallel。爲得到更好的響應性能，應該使用併發垃圾回收器：-Xgc:gencon，可使用-Xms和-Xmx設置堆棧的初始大 小和最大值,要設置護理域-Xns爲-Xmx的10%。而如果要得到更好的性能，應該選用並行垃圾回收器:-Xgc: parallel，由於並行垃圾回收器不使用nursery，不必設置-Xns。

　　如果你的線程大於100或者在linux平臺下，可以嘗試使用瘦線程模式：-Xthinthread,同時關閉Native IO:-Xallocationtype:global。

　　jRockit 還提供了強大的圖形化監控工具Jrockit Management Console。欲詳細瞭解JRockit可訪問：http://edocs.bea.com/wljrockit/docs81/index.html。

2.2 Server調優
　　WebLogic Server的核心組件由監聽線程,套接字複用器和可執行線程的執行隊列組成。當服務器由監聽線程接收到連接請求後,將對它的連接控制權交給等待接收請求 的套接字複用器。然後套接字複用器讀取離開套接字的請求,並將此請求及相關安全信息或事務處理環境一起置入適當的執行隊列中(一般爲默認的執行隊列)。 當有一個請求出現在執行隊列中時，就會有一個空閒的執行線程從該隊列中取走發來的該請求，並返回應答，然後等待下一次請求。因此要提高WebLogic的性能,就必須從調整核心組件性能出發。

2.2.1 儘量使用本地I/O庫
WebLogic Server有兩套套接字複用器：Java版和本地庫。採用小型本地庫更有效,儘量激活Enable Native IO(默認),此時UNIX默認使用CPUs+1個線程,Window下爲雙倍CPU。如果系統不能加載本地庫,將會拋出 java.lang.UnsatisfiedLinkException,此時只能使用Java套接字複用器,可以調整socket readers 百分比,默認爲33%。該參數可以在Console Server Tuning Configuration配置欄裏設置。

2.2.2 調整默認執行線程數
　 　理想的默認執行線程數是由多方面的因素決定的,比如機器CPU性能、總線體系架構、I/O、操作系統的進程調度機制、JVM的線程調度機制。 WebLogic生產環境下默認的線程爲25個,隨着CPU個數的增加,WebLogic可以近乎線性地提高線程數。線程數越多，花費在線程切換的時間也 就越多,線程數越小,CPU可能無法得到充分利用。爲獲取一個理想的線程數,需要經過反覆的測試。在測試中,可以以25*CPUs爲基準進行調整。當空閒 線程較少,CPU利用率比較低時,可以適當增加線程數的大小(每五個遞增)。對於PC Server 和Window 2000，則最好每個CPU小於50個線程, 以CPU利用率爲90%左右爲佳。由於目前WebLogic執行線程沒有縮小線程數的功能,所以應將參數Threads Increase設置爲0,同時不應改變優先級的大小。

2.2.3 調整連接參數
　 　WebLogic Server用Accept Backlog參數規定服務器向操作系統請求的隊列大小，默認值爲50。當系統重載負荷時,這個值可能過小,日誌中報Connection Refused,導致有效連接請求遭到拒絕,此時可以提高Accept Backlog 25%直到連接拒絕錯誤消失。對於Portal類型的應用,默認值往往是不夠的。Login Timeout和SSL Login Timeout參數表示普通連接和SSL連接的超時時間,如果客戶連接被服務器中斷或者SSL容量大,可以嘗試增加該值。這些參數可以在Console Server Tuning Configration配置欄裏找到。

2.2.4 創建新的執行隊列
　 　創建新的執行隊列有助於解決核心業務優先、避免交叉阻塞、死鎖和長時間處理的業務等問題。通常會將自己的執行隊列和默認的執行隊列設置不同的優先級,這 裏優先級不應設爲9或者10。 定義一個新的執行隊列很容易,利用View Excute Queue選項中的Configure a new Excute Queue鏈接即可定製新的執行隊列。創建新的執行隊列後，用戶需要爲應用程序的J2EE組件配置分配策略，以便它可以找到新的隊列。舉個例子：要將 servlet或jsp捆綁到一個特定的執行隊列，必須替換web.xml文件項，將wl-dispatch-policy初始化參數設置爲自己的執行隊 列名。

<servlet>
<servlet-name>servletname</servlet-name>
<jsp-file>/directoryname/deployment.jsp</jsp-file>
<init-param>
<param-name>wl-dispatch-policy</param-name>
<param-value>NewExecuteQueueName</param-value>
</init-param>
</servlet>

　　我們可以爲一個jsp或者servlet乃至一個WEB應用設置自己的執行隊列。同時也可以爲EJB設置自己的執行隊列。對於執行時間比較長的MDB,建議使用自己的執行隊列。

2.3 JDBC調優
2.3.1 調整連接池配置
　 　JDBC Connection Pool的調優受制於WebLogic Server線程數的設置和數據庫進程數,遊標的大小。通常我們在一個線程中使用一個連接,所以連接數並不是越多越好,爲避免兩邊的資源消耗，建議設置連 接池的最大值等於或者略小於線程數。同時爲了減少新建連接的開銷,將最小值和最大值設爲一致。

　　增加Statement Cache Size對於大量使用PreparedStatement對象的應用程序很有幫助,WebLogic能夠爲每一個連接緩存這些對象,此值默認爲10。在保 證數據庫遊標大小足夠的前提下,可以根據需要提高Statement Cache Size。比如當你設置連接數爲25,Cache Size爲10時,數據庫可能需要打開25*10=250個遊標。不幸的是,當遇到與PreparedStatement Cache有關的應用程序錯誤時,你需要將Cache Size設置爲0。

　　儘管JDBC Connection Pool提供了很多高級參數,在開發模式下比較有用,但大部分在生產環境下不需調整。這裏建議最好不要設置測試表, 同時Test Reserved Connections和Test Released Connections也無需勾上。 當然如果你的數據庫不穩定,時斷時續,你就可能需要上述的參數打開。

　　最後提一下驅動程序類型的選擇,以Oracle爲 例,Oracle提供thin驅動和oci驅動,從性能上來講,oci驅動強於thin驅動,特別是大數據量的操作。但在簡單的數據庫操作中,性能相差不 大,隨着thin驅動的不斷改進,這一弱勢將得到彌補。而thin驅動的移植性明顯強於oci驅動。所以在通常情況下建議使用thin驅動。而最新驅動器 由於WebLogic server/bin目錄下的類包可能不是最新的,請以Oracle網站爲準: http://www.oracle.com/technology/software/tech/java/sqlj_jdbc/htdocs/jdbc9201.html。

2.4 WEB調優
2.4.1 調整WEB應用描述符
　 　WEB應用除代碼之外的調優比較簡單,僅僅是對一些WEB應用描述符的調整。首先關閉Session Monitoring Enabled,僅僅在Cluster環境下設置Session複製(優先使用內存複製),在保證應用正常運行的情況下,設置較短的Session超時時 間。 同時生產環境下無需檢查Jsp和servlet：JSPPage Check Secs和Servlet Reload Check Secs均設爲-1,關閉JSPKeep Generated 和JSPVerbose對性能也有幫助。此外，還可以對jsp進行預編譯,有兩種方法：激活precompile選項；使用weblogic.appc事 先編譯，建議採用後者。

2.5 JMS調優
　　1. 增加-Dweblogic.JMSThreadPoolSize=n(至少爲5),以提高處理JMS的線程數,在jRockit上增加-XXenablefatspin以減少加鎖衝突;
　　2. 採用文件存儲策略,將同步寫策略設置爲Direct-Write,同時在windows平臺上啓用磁盤寫入緩存;
　　3. 使用分佈式目的地時,激活連接工廠Load Balancing Enabled ,Server Affinity Enabled;
　 　4. 爲減少服務器不必要的JMS請求路由,如果多個目的地之間存在事務,則部署在同一JMS服務器上,儘量將連接工廠部署到JMS服務器所在的 WebLogic實例上,集羣環境下，則最好將連接工廠部署到集羣中的所有服務器上,而集羣中每個JMS服務器和目的地成員儘量使用類似的設置；
　　5. 啓用消息分頁存儲功能,以釋放內存,可以爲JMS服務器和目的地設置, 激活Messages Paging Enabled和Bytes Paging Enabled,同時使用限額防止服務器耗盡接收消息的所有可用內存空間;
　　6. 在運行WebLogic Server進程之外的生產者務必使用流控制, 並增大Send Timeout;
　　7. 將JMS Server Expiration Scan Interval設很大的值，能禁止主動掃描過期消息;
　　8. 使用FIFO或者LIFO方式處理目的地消息;
　　9. MDB的max-beans-in-free-pool不應大於最大MDB線程數(默認線程數/2+1)。

2.6 EJB調優
2.6.1 調整pool和cache
　 　initial-beans-in-free-pool定義SLSB啓動時實例的個數,默認爲0,可以調大到正常併發數的大小,以減少初始響應時間。 max-beans-in-free-pool爲最大個數,默認1000對SLSB來說,在頻繁創建和刪除實例的情況下很有幫助,一般不用調整,至少設爲 默認線程數,過大容易造成內存溢出。而對Entity Bean來說,由於是匿名的,所以當頻繁使用finder、home和create方法時可以調大。

　　對SFSB來說,儘量將max- beans-in-cache參數設置得足夠的大，以滿足Bean實例對最大併發用戶數的要求，可以避免有狀態會話Bean過多的鈍化行爲。而idle- timeout-seconds儘量設置小,如果SFSB不用於存儲Web應用會話狀態可以設置爲0。

　　對於Entity Bean來說, max-beans-in-cache同樣可以首先採用默認值1000，監控實例緩存和鈍化的情況,再做適當調整。

　 　並行策略concurrency-strategy定義了實體Bean如何管理鎖,有四種策略: Exclusive、Databse、ReadOnly、Optimistic。效率依次提高,可靠性依次降低,儘量避免使用互斥策略,如果Bean無需 更新操作,使用只讀策略,更甚的是,如果Bean的內容不會改變,可設置read-timeout-seconds爲0,樂觀並行策略時採用事務間緩存策 略,在entity-cache描述符中將cache-between-transactions元素設爲true。

2.6.2 優化事務隔離級別和事務屬性
　　對EJB組件來說，有四種事務隔離水平：

• TRANSACTION-SERIALIZABLE：在處理完成之前拒絕其他處理的讀入、可擴展性或插入數據操作;
• TRANSACTION-REPEATABLE-READ：防止處理修改正在被其他處理調用的數據;
• TRANSACTOIN-READ-COMMITTED：防止對正在被其他處理修改的數據執行寫鎖定；
• TRANSACTION-READ-UNCOMMITTED：允許處理讀入未受權的數據以及允許在向結果中添加記錄時可以忽略處理。

　　 以上隔離水平依次降低,效率和性能依次提高。因此,建議選用滿足在業務數據完整性要求前提下水平最低的隔離級別。

　　對於事務屬性的設置也是如此,對於刪除、修改和插入操作設置爲Required,而對於只讀操作設置爲Supports或者NotSupports。

2.6.3 其他一些小技巧
　　1. 利用finders-load-bean的默認值true，既可以避免“n+1”的查詢問題，又可以提高系統的性能;
　　2. 使用delay-updates-until-end-of-tx參數的默認值true，除非應用程序對某些變化有特別的要求;
　　3. 應用程序在每個業務方法調用後不需要進行存在性檢查，將check-exists-on-method設定爲false，以提高程序的性能;
　　4. 同一應用內, 將enable-call-by-reference設置爲 true;
　　5. reentrant設置爲false,避免事先加載子數據。

第三章 數據庫調優(目錄)
3.1.1 Oracle性能優化
　　Oracle9i的性能優化除了調整kernal之外就是主要對Oracle啓動文件的調整,即調整SGA的參數。注意,不同操作系統不同位數的機器最優的參數不是一樣的,這裏主要有windows和unix之分,32位和64位之分。
首先需要調大進程數和遊標數,一般默認的值對實際應用來說都比較小,比如說,進程數可以調到300,遊標數可以調到500。

　 　其次,看一個經驗公式: OS 使用內存+ SGA + session*(sort_area_size + hash_area_size +2M)<0.7RAM,通常認爲此時的SGA比較合理。這裏sort_area_size爲64k, hash_area_size爲128k(當排序多的時候需要增大sort_area_size,按調整後的值計算),session表示最大併發進程 數,假設100個。假如1G內存的機器,OS佔用200M,PGA佔用200M左右,那麼SGA可以設爲400-500M，如果2G內存可以1G給 SGA，8G可以5G給SGA。不過對於32位數據庫來說，通常最多隻能使用1.7G內存。

　　然後，SGA內參數設置的基本原則 是：data buffer 通常可以儘可能的大，shared_pool_size 要適度，log_buffer 通常大到幾百K到1M就差不多。具體的：data buffer 1G內存可以設置500M，2G設爲1.2G，8G可設爲5G 。shared_pool_size不易過大，通常應該控制在200M--300M,如果使用了大量的存儲過程，可以根據SGA的值增大到500M，如果 增大後命中率得不到提高，則增加是無益的。具體的：1G內存可以設置100M，2G設爲150M，8G可設爲300M。如不使用 Java，java_pool_size 10-20M即可。large_pool_size如果不設置MTS，在20M -30M 即可，假如設置 MTS,可以考慮爲 session * (sort_area_size + 2M)。

　　最後，關於內存的設置可根據statspack信息和v$system_event,v$sysstat,v$sesstat,v$latch 等view信息來考慮微調。

3.1.2 Oracle的其他調整
　　爲了Oracle高效率的運行，除了上面提到的內存因素之外，還有就是需要良好的數據庫設計：表、視圖、索引和日誌的合理規劃和建立。I/O的性能也是重要因素，應儘量減少頁交換和頁分配。此外，就是改善檢查點的效率。

第四章 操作系統調優(目錄)
4.1 操作系統調整
　 　操作系統影響應用程序運行性能的因素主要有：硬件的配置(CPU、內存、硬盤等),核心參數,TCP/IP參數以及補丁的情況等。這裏對操作系統的優 化,除了更新最新的補丁程序以保證應用程序正常運行之外,就是調整TCP/IP參數,文件描述符,對於個別操作系統還有其他特別的參數調整。下面將依次介 紹不同操作系統的情況,更多的信息請參考各操作系統的文檔。

4.1.1 HP-UX
　　對於HP-UX,你首先需要安裝Java Patch:
http://www.hp.com/products1/unix/java/patches/index.html,然後需要確認下面文檔中的核心參數是否滿足(可以使用sam命令修改核心參數):http://e-docs.bea.com/platform/suppconfigs/configs81/hpux11_risc/81sp3.html#80105。

　　調整TCP參數: ndd -set /dev/tcp tcp_conn_req_max 1024, 將偵聽隊列的最大允許長度調整到1024。 有時操作系統限制進程使用的最大內存數小於你要配置的內存大小,則需要調整該值。

　　讀者可以從http://docs.hp.com/hpux/onlinedocs/TKP-90203/TKP-90203.html瞭解更多的HP-UX調整建議。

4.1.2 Solaris
　　調整TCP的參數,等待時間間隔tcp-time-wait-interval建議設置爲60000ms: /usr/sbin/ndd ?set /dev/tcp tcp_time_wait_interval 60000;
其他參數調整如下:

tcp_xmit_hiwat/tcp_recv_hiwat 131072
tcp_conn_req_max_q/tcp_conn_req_max_q0 16384

　　調整一個進程打開的文件描述符的數量:軟限制和硬限制以及散列表的大小,修改/etc/system文件:

set tcp:tcp_conn_hash_size=32768
set rlim_fd_cur=8192
set rlim_fd_max=8192

更多的調整信息請查閱: http://docs.sun.com/db/doc/806-7009(Solaris9)。

4.1.3 AIX
　 　AIX用no命令調整TCP參數，等待時間間隔tcp_timewait: no -o tcp_timewait=4,將tcp.timewait參數設置爲4個15秒間隔，即1分鐘。運行no -a命令將顯示網絡當前的所有屬性值。由於UDP_SENDSPACE默認的緩存大小是8k,爲減少I/O異常,需調整爲32k:

　　no -o udp_sendspace=32768。此外, 當WebLogic HTTP請求忙時,可以調整偵聽隊列的最大長somaxconn到8192(默認值是1024)。

　　更多信息:http://publib16.boulder.ibmo.com/pseries/en-us/aixbman/prftungd/prftungd.htm。

4.1.4 Linux
　 　調整Linux系統使用sysctl命令修改TCP參數等待時間間隔:sysctl -w ip_ct_tcp_timeout_time_wait=60;調整打開文件的最大數:在/etc/sysctl.conf文件中，添加: Fs.file-max=65535,然後運行sysctl -p;調整打開文件描述符最大數爲8192:在/etc/security/limits.conf文件，添加:WebLogic hard nofile 8192(僅針對WebLogic用戶),然後在WebLogic啓動文件裏運行ulimit-n 8192激活設置。

更多信息請查閱:http://ipsysctl-tutorial.frozentux.net/ipsysctl-tutorial.html。

4.1.5 Windows
　 　Windows系統的調整通過修改註冊表HKEY-LOCAL-MACHINESYSTEMCurrent ControlSetServices文件夾來完成。可以調整TcpipParameters子文件夾中的等待時間間隔時間 TcpTimedWaitDelay參數的值。偵聽隊列最大長度的默認值爲15，爲修改它，可在InetinfoParameters子目錄中創建 DWORD條目ListenBackLog。
此外,Windows2000的Service Pack(要求sp3以上)也會影響系統穩定性: http://e-docs.bea.com/platform/suppconfigs/configs81/win2ksvr_as_data_pentium/81sp3.html。

第五章 性能監控和性能分析(目錄)
5.1 性能瓶頸
　　最後,介紹一下實際分析J2EE應用性能的常用命令和工具。對於實現一個高性能的J2EE應用來說,掌握了J2EE調優的理論經驗還是不夠的。掌握性能監控,發現瓶頸和問題診斷纔是保證J2EE系統持續高效運行的關鍵。
瓶 頸指的是限值所有吞吐操作以及嚴重影響反應時間的系統內資源。在分佈式系統內尋找並糾正瓶頸是非常困難的，需要有經驗的團隊來解決。瓶頸會發生在Web服 務器上，程序代碼中，應用服務器上，數據庫，操作系統或者網絡，硬件上。經驗表明，瓶頸很容易發生在如下地方：數據庫連接與隊列中；應用服務器的程序代碼 中；應用服務器和Web服務器硬件上；網絡和TCP配置中。實際中可以着力對這些環節進行監控。

5.2 操作系統監控
　 　操作系統層面的性能監控主要是對內存、CPU、I/O和交換區的使用情況進行監控分析。windows平臺可以通過任務管理器和perfmon工具查 看。如果是unix系統可以使用stat系列命令(vmstat, mpstat, iostat)監控內存、CPU和I/O的即時變化,使用swap命令查看交換區的使用情況。如果操作系統安裝了top、topas、glance等使用 工具,則使用top、topas、glance將能更爲方便地看到WebLogic進程對操作系統的內存,CPU和I/O資源使用的即時變化情況。

　　而網絡方面的性能可以通過ping和netstat等命令來監控,主要幾個關鍵的網絡統計值,如數據包再發送、重複數據包和數據包偵聽丟失。

　　說明:本文提到的unix命令並非適用所有操作系統,僅供參考。

5.3 數據庫監控
　　數據庫層面的監控這裏爲oracle9i爲例來說明,可以採用oracle自帶的工具Oracle
Interprise Manager Console來監控session和sql的執行情況。還有其他專業的數據庫監控工具可以使用,比如QUEST的spotlight(http://www.quest.com/spotlight-portal/)可以非常形象和直觀地對Oracle數據庫的CPU、內存、I/O、Data Buffer Size、Shared Pool Size、Redo Buffer等參數進行即時監控,並自動對不正常的參數以紅色顯示。

5.4 WebLogic監控
5.4.1 JVM監控
　　採用java參數-verbose:gc 來分析JVM的GC非常繁瑣，而且不直觀。使用-Xloggc:gc.log 參數將GC日誌寫入文件,採用GC 工具HPjtune (http://www.javaperformancetuning.com/tools/hpjtune/index.shtml)進行分析,可以輕鬆看出當前jvm參數配置是否合理。

　 　嚴格意義上來說HPjtune是一個分析工具,不是監控工具。這裏不得不提及jRocket,Intel平臺上最快的JVM, 在WebLogic啓動命令中增加-Xmanagement參數,就可以執行beajrockit81sp3_142_04in下console命令監 控WebLogic的內存使用和CPU負載情況。設置Tools/Preferences菜單中的Mode of operation屬性爲developer, jRocket將提供Method Profiler工具，她能夠將所有在JRockit Java虛擬機上執行的成員方法的調用次數、執行的總時間和每次調用的執行時間都統計出來，進行代碼級調優，這是jRockit的又一大優勢。

5.4.2 Console監控
　　WebLogic Console除了管理配置功能之外,提供了豐富的監控功能。通過WebLogic Console，首先我們可以查看服務器的運行情況。

5.4.2.1 Server監控
　 　通過使用服務器的Performance Monitoring選項卡，可以查看到請求吞吐量，執行隊列積壓情況以及JVM棧利用情況。而通過點擊Performance Genaral選項卡中” Monitor all Active Queues...”可以查看所以執行線程的當前統計數據。此外Monitoring選項卡還可以監控JTA和JMS等Service的情況。

5.4.2.2 JDBC監控
　　在連接池Monitoring選項卡中，WebLogic Console爲每一個數據庫連接池提供了實時統計信息。其中有三個重要參數可以反應WebLogic Server的健康狀況：Connections High、Wait Second High和Waiters High。Connection High表示從服務器啓動開始後到達池的最大連接數量，如果大於池的最大數量，則需要調整Maxium Capacity。Waiters High表示在沒有可用連接的情況下，應用程序等待連接的最大個數。我們可以根據Waiters High的大小調整連接池容量。更多的參數可以通過Customize this view鏈接添加,參數含義參考:http://e-docs.bea.com/wls/docs81/ConsoleHelp/domain_jdbcconnectionpool_monitor.html#1104829。

5.4.2.3 WEB監控
　　Web Application Monitoring選項卡可以監控WEB應用的Session個數,以及Servlet的響應情況,激活Session Monitoring Enabled可以獲取所有session的統計情況。更多信息請參考:
http://e-docs.bea.com/wls/docs81/ConsoleHelp/web_applications.html#1106723。

5.4.2.4 JMS監控
　 　Welogic Console JMS監控功能比較多,不僅在Server JMS Monitoring選項卡可以監控Active JMS Connections, Pooled JMS Connections和Active JMS Servers的連接和使用情況。還可以監控JMS Session Pool、Active JMS Destinations和Durable Subscribers的消費和生產情況。比如,我們可以監控到JMS Queue的接收和消費消息的數量和字節數。有關JMS監控的詳細情況可參見:http://edocs.bea.com/wls/docs81/ConsoleHelp/jms_monitor.html。

5.4.2.5 EJB監控
　　EJB監控包括對SLSB,SFSB,Entity Bean,MDB四種EJB的監控。本人認爲EJB監控提供了非常豐富的運行時統計信息(http://e-docs.bea.com/wls/docs81/ConsoleHelp/ejb.html#1105036),非常有利於我們對EJB進行性能調優。

　 　SLSB選項卡爲用戶提供實例池的運行時統計信息。Pool Miss Ratio 表示實例池的Miss率,Pool Waiter Total Count 表示線程等待bean 實例的累計時間,Pool Timeout Total Count表示超時的線程數。當Pool Miss Ratio較大時,可以增加max-beans-free-pool。

　　SFSB可以關注Cache Miss Ratio和Activation Count。Cache Miss Ratio過大時,調大max-bean-in-cache未必有幫助,需要嘗試不用的max-bean-in-cache以獲得最低的Cache Miss Ratio。激活將嚴重減慢應用程序的速度,如果某一個bean的Activation Count的值過高，那麼需要考慮增加max-bean-in-cache的大小。
Entity Bean結合了SLSB的free pool和SFSB的cache。可以結合上面的策略進行監控。

　　而MDB僅比SLSB多一個參數JMSConnection Alive,報告EJB是否成功連接到JMS目的地。

更多Console監控信息可參見http://edocs.bea.com/wls/docs81/ConsoleHelp/index.html。

5.4.3 實用工具分析
　 　WebLogic除了提供Console進行應用監控之外,用戶還可以編寫JMX程序或者通過SNMP協議進行監控。而QUEST Spotlight for WebLogic Server提供了類似WebLogic Console類似的監控功能,並對異常情況顯紅。
這裏不得不提到實戰中 經常用來分析性能瓶頸的工具THREAD DUMP,統一的命令是使用 weblogic.Admin 命令 THREAD_DUMP。而在 windows上還可以使用<Ctrl>+<Break> 來創建診斷問題所需的線程轉儲Thread Dump,而在unix上使用kill -3 <wlspid>命令。我們從中可以看到WebLogic後臺線程的運行情況,通常需要每隔10秒左右持續執行幾次以助診斷問題。更多信息可 以參考BEA實戰集錦。

5.5 應用程序分析
　　應用程 序分析除了憑藉程序員豐富的經驗和敏銳的洞察力去人工檢查代碼之外,使用廠家的工具也是節省時間的不錯選擇。目前市場上有Borland Optimizeit Enterprise Suite和QUEST Jprobe兩個產品可以用來分析性能瓶頸,垃圾收集,內存泄漏,線程死鎖和代碼覆蓋等。Hpjmeter是一個免費的工具,也具有以上類似的性能分析功 能。

　　而Borland Optimizeit Server Trace,HP OpenView Transaction Analyzer和Mercury LoadRunner J2EE breakdown都可以用來分解J2EE應用從客戶端訪問到最終數據庫操作每一層次花費的時間,甚至精確到每一個方法的執行時間。Server Trace還具有檢查內存泄漏，連接泄漏和錯誤警告等功能,一般在測試環境中使用。而HP OTVA的優勢在於運行時監控,LoadRunner優勢在於壓力測試。