weblogic 優(yōu)化大全.doc

WebLogic優(yōu)化大全摘要：隨著近來J2EE軟件廣泛地應用于各行各業(yè)，系統(tǒng)調(diào)優(yōu)也越來越引起軟件開發(fā)者和應用服務器提供商的重視。而對于最終客戶來說，在一個高效、穩(wěn)定地實現(xiàn)他們的業(yè)務需求已經(jīng)是他們的基本要求。所以J2EE調(diào)優(yōu)顯得非常重要，而BEA WebLogic Server是業(yè)界領先的應用服務器，BEA WebLogic平臺下的J2EE調(diào)優(yōu)也就尤為重要,她將為我們提供普遍的J2EE調(diào)優(yōu)方案。最近網(wǎng)絡、雜志上的J2EE調(diào)優(yōu)文章層出不窮。本人也將自己平時工作中的一些經(jīng)驗積累分享給大家，拋磚引玉。前 言 隨著近來J2EE軟件廣泛地應用于各行各業(yè)，系統(tǒng)調(diào)優(yōu)也越來越引起軟件開發(fā)者和應用服務器提供商的重視。而對于最終客戶來說，在一個高效、穩(wěn)定地實現(xiàn)他們的業(yè)務需求已經(jīng)是他們的基本要求。所以J2EE調(diào)優(yōu)顯得非常重要，而BEA WebLogic Server是業(yè)界領先的應用服務器，BEA WebLogic平臺下的J2EE調(diào)優(yōu)也就尤為重要,她將為我們提供普遍的J2EE調(diào)優(yōu)方案。最近網(wǎng)絡、雜志上的J2EE調(diào)優(yōu)文章層出不窮。本人也將自己平時工作中的一些經(jīng)驗積累分享給大家，拋磚引玉。本文從J2EE應用架構（下圖）來分別剖析系統(tǒng)調(diào)優(yōu)，首先我們一般會從應用程序出發(fā)，去審核代碼，做到代碼級的優(yōu)化，然后再調(diào)整應用服務器(BEA WebLogic8.1)和數(shù)據(jù)庫 (Oracle9i)的參數(shù)，最后當然是調(diào)整操作系統(tǒng)和網(wǎng)絡的性能(包括硬件升級)。誠然,在我遇到的很多項目中,都是出現(xiàn)了性能問題后才想到調(diào)優(yōu),而且一般都是先進行系統(tǒng)參數(shù)調(diào)整,實在解決不了才會對代碼進行檢查.實際上,我們應當將代碼級的調(diào)優(yōu)放在應用設計時來做,測試生產(chǎn)時修改代碼將是一件極其痛苦的事情。WebLogic平臺J2EE應用架構第一章 應用程序調(diào)優(yōu)1.1.1 通用代碼調(diào)優(yōu)1.1.2 減小沒有必要的操作對象的創(chuàng)建是個很昂貴的工作,所以我們應當盡量減少對象的創(chuàng)建,在需要的時候聲明它,初始化它,不要重復初始化一個對象,盡量能做到再使用,而用完后置null有利于垃圾收集。讓類實現(xiàn)Cloneable接口,同時采用工廠模式,將減少類的創(chuàng)建,每次都是通過clone()方法來獲得對象。另外使用接口也能減少類的創(chuàng)建。對于成員變量的初始化也應盡量避免, 特別是在一個類派生另一個類時。異常拋出對性能不利。拋出異常首先要創(chuàng)建一個新的對象。Throwable接口的構造函數(shù)調(diào)用名為, fillInStackTrace()的本地（Native）方法，fillInStackTrace()方法檢查堆棧，收集調(diào)用跟蹤信息。只要有異常被拋出，VM就必須調(diào)整調(diào)用堆棧，因為在處理過程中創(chuàng)建了一個新的對象。 異常只能用于錯誤處理，不應該用來控制程序流程。此外, 建議關閉Debug輸出,盡量少用串行化、同步操作和耗時昂貴的服務(如Date()。1.1.3 使用合適的類型當原始類型不能滿足我們要求時,使用復雜類型。String和StringBuffer的區(qū)別自不必說了,是我們使用最多的類型,在涉及到字符運算時,強烈建議使用StringBuffer。在做String匹配時使用intern()代替equal()。帶有final修飾符的類是不可派生的, 如果指定一個類為final，則該類所有的方法都是final。Java編譯器會尋找機會內(nèi)聯(lián)所有的final方法,這將能夠使性能平均提高50%。類的屬性和方式使用final或者static修飾符也是有好處的。調(diào)用方法時傳遞的參數(shù)以及在調(diào)用中創(chuàng)建的臨時變量都保存在棧（Stack）中，速度較快。所以盡量使用局部變量。ArrayList和Vector,HashMap和Hashtable是我們經(jīng)常用到的類,前者不支持同步,后者支持同步,前者性能更好,大多數(shù)情況下選擇前者。1.1.4 盡量使用pool,buffer和cache使用pool、buffer和cache能大大提高系統(tǒng)的性能,這在J2EE的大部分技術中都是適用的。在WebLogic中就大量使用了池:JDBC Connection Pool、Socket Pool、Object Pool和Thread Pool。I/O操作中,buffer是必須的,特別是對大文件的操作,不然容易造成內(nèi)存溢出。字節(jié)操作最快,所以盡可能采用write(byte )，Buffered FileOutputStream比Buffered FileWriter要快,因為FileWriter需要Unicode到Byte的轉(zhuǎn)換。而后面講到的JDBC、JSP、EJB和JMS我們都非常建議使用buffer和cache。為HttpServletResponse設置buffersize,使用wl-cache,緩存在JNDI樹上獲取的對象等等。此外,使用JDK 1.4的非阻塞I/O對性能也有很大提高。 1.2 JDBC代碼調(diào)優(yōu)1.2.1 嚴格資源使用JDBC代碼調(diào)優(yōu)最大的原則就是使用WebLogic的連接池,而不是自己直連數(shù)據(jù)庫。在我接觸的很多自己實現(xiàn)連接池的項目中,大部分遇到死鎖和連接泄漏的問題，最后得不得修改代碼。而WebLogic提供了功能強大，性能良好的數(shù)據(jù)庫連接池，我們要做的只是封裝一個連接管理類，從JNDI樹上獲取數(shù)據(jù)源并緩存，得到連接，并提供一系列關閉數(shù)據(jù)庫資源的方法。對任何資源使用的原則是用完即關，不管是數(shù)據(jù)庫資源、上下文環(huán)境，還是文件。數(shù)據(jù)庫資源的泄漏極易造成內(nèi)存泄漏，乃至系統(tǒng)崩潰。在使用完數(shù)據(jù)庫資源后依次關閉ResultSet，Statement和Connection，而在一個數(shù)據(jù)庫連接多次進行數(shù)據(jù)庫操作時要特別注意ResultSet和 Statement依次關閉。try/open connectionpstmt =conn.prepareStatement(strSql1);pstmt.executeUpdate();pstmt.close();pstmt =conn.prepareStatement(strSql2);rs=pstmt.executeQuery();while (rs.next()/processrs.close();pstmt.close();catch(Exception e)/close rs,psmt,confinally/close rs,psmt,con1.2.2 實用技巧在JDBC操作中還有一些小的技巧跟大家分享：由于獲取連接時默認自動提交方式，使用 connection.setAutoCommit(false) 關閉自動提交，使用PreparedStatement,批量更新,業(yè)務復雜或者大數(shù)據(jù)量操作時使用存儲過程，盡量使用RowSet，此外設置記錄集讀取緩存FetchSize和設置記錄集讀取方向FetchDirection對性能也有一定的提高。1.2.3 優(yōu)化SQL語句SQL語句的優(yōu)化牽涉到很多數(shù)據(jù)庫的知識，需要與索引配合，因此需要DBA對代碼中的SQL進行檢查測試。常見的，select *不提倡使用，效率極差，建議顯式獲取列，即使是所有字段也應羅列，而取總數(shù)時使用count(*),為提高cache的命中率，盡量做到SQL重用。對于大數(shù)據(jù)量的查詢，可以充分利用Oracle數(shù)據(jù)庫的特性，每次取出m-n行的數(shù)據(jù)，實現(xiàn)分頁查詢。另外，提高性能的好選擇可能就是把所有的字符數(shù)據(jù)都保存為Unicode，Java以Unicode形式處理所有數(shù)據(jù)，因此，數(shù)據(jù)庫驅(qū)動程序不必再執(zhí)行轉(zhuǎn)換過程。1.3 Web代碼調(diào)優(yōu)1.3.1 HttpSession的使用應用服務器保存很多會話時，容易造成內(nèi)存不足，所以盡量減少session的使用，放置session里的對象不應該是大對象，最好是簡單小對象，實現(xiàn)串行化接口。當會話不再需要時，應當及時調(diào)用invalidate()方法清除會話。而當某個變量不需要時，及時調(diào)用removeAttribute()方法清除變量。請勿將EJB對象放置在session中。1.3.2 JSP代碼調(diào)優(yōu)目前，在JSP頁面中引入外部資源的方法主要有兩種：include指令，以及include動作。 include指令：例如，該指令在編譯時引入指定的資源。在編譯之前，帶有include指令的頁面和指定的資源被合并成一個文件。被引用的外部資源在編譯時就確定，比運行時才確定資源更高效。include動作：例如。該動作引入指定頁面執(zhí)行后生成的結果。由于它在運行時完成，因此對輸出結果的控制更加靈活。但是，只有當被引用的內(nèi)容頻繁地改變時，或者在對主頁面的請求沒有出現(xiàn)之前，被引用的頁面無法確定時，使用include動作才合算。 對于那些無需跟蹤會話狀態(tài)的jsp，關閉自動創(chuàng)建的會話可以節(jié)省一些資源。使用如下page指令： ;盡量不要將JSP頁面定義為單線程，應設置為;在JSP頁面最好使用輸出緩存功能，如: ;盡量用wl:cache定制標記來緩存靜態(tài)或相對靜態(tài)的內(nèi)容，緩存jsp:include操作的結果能顯著提高應用程序的運行性能。1.3.3 Servlet代碼調(diào)優(yōu)Servlet代碼調(diào)優(yōu)比較簡單：在Servlet之間跳轉(zhuǎn)時，forward比sendRedirect更有效；設置 HttpServletResponse 緩沖區(qū)，如：response.setBufferSize(20000);在init()方法里緩存靜態(tài)數(shù)據(jù)，而在destroy()中釋放它；建議在 Servlet里使用ServletOutputStream輸出圖片等對象；避免在Servlet和Jsp中定界事務等。1.4 JMS代碼調(diào)優(yōu)1.4.1 注意必要的事項，避免使用不必要的特征JMS提供了強有力的消息處理機制，但是為了最大限度的提高JMS系統(tǒng)的性能，應避免使用不需要使用的特征，同時也要注意必要的事項。比如：盡量使用接收程序能直接使用的最簡單、最小的消息類型；消息選擇器要盡可能簡單(最好不使用)，盡量不要使用復雜的操作符，如like、in或者between 等, 使用字符串數(shù)據(jù)類型的速度最慢;務必為特定的應用程序定義特定的JMS連接工廠，并且禁用默認的JMS連接工廠；不要在javax.*與 weblogic.*的名字空間中使用JNDI名稱；盡量使用異步消費者，線程不必封鎖以等待消息的到達;使用完JNDI樹上的資源后注意關閉。1.4.2 消息類型的選擇標準JMS提供了五種消息類型，而TextMessage應用最為普遍, 當發(fā)送的消息是幾種原始數(shù)據(jù)類型的集合體時，最好使用MapMessage消息類型，而不要使用ObjectMessage，以便減少不同系統(tǒng)間的耦合。此外消息是否使用壓縮要慎重考慮，壓縮未必能減少消息大小。如果生產(chǎn)者、消費者和目的地并置在同一WebLogic Server內(nèi)部，通常不使用壓縮。WebLogic特有的XMLMessage能為運行于消息主體之上的消息選擇器提供內(nèi)嵌式支持，而且易于數(shù)據(jù)交換。因此，建議應用程序之間傳送消息使用XML消息格式，而應用程序內(nèi)部間傳送消息使用二進制消息格式。1.4.3 確認方式的選擇和JMS事務使用事務性會話時,盡量使用恰當?shù)南⒋_認方式:如果需求允許,使用NO_ACKKNOWLEDGE;非持久的訂閱者使用 DUPS_OK_ACKNOWLEDGE或者MULTICAST_NO_ACKNOWLEDGE。而使用JTA的UserTransaction，確認方式將被忽略。在使用JMS事務時，無效的消息會導致事務的回滾，以致消息重發(fā)這樣的死循環(huán)。此時，可以將無效消息發(fā)送到錯誤消息隊列，并提交JMS事務，這將確保消息不會再次傳遞。1.5 EJB代碼調(diào)優(yōu)1.5.1 有效使用設計模式GoF 的設計模式為我們實現(xiàn)高性能、易擴展的J2EE應用提供理論保障和技術支持。而EJB作為J2EE的核心組件和技術，善用設計模式對系統(tǒng)性能影響很大。Service Locator 和Value Object 已為我們所熟悉，F(xiàn)loyd 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；封裝業(yè)務邏輯在輕量級JavaBean中；使用值對象等簡單對象傳遞數(shù)據(jù);不直接使用get/set方法操作Entity Bean。當然過度使用模式或者牽強套用模式也是不提倡的，總的原則就是減少網(wǎng)絡流量，改進事務管理。1.5.2 使用EJB和WebLogic的特性使用EJB和WebLogic的新特性往往能提高性能。與EJB2.0特性相關的技巧有：一個Application中使用本地接口，對于 Entity Bean肯定使用本地接口，避免遠程調(diào)用的開銷；使用CMP管理關系，而不是BMP，EJB2.0中CMP的性能大大改善，性能和移植性都優(yōu)于BMP；使用ejbSelect進行內(nèi)部查詢；使用home方法進行外部查詢和批處理; 數(shù)據(jù)庫驅(qū)動級聯(lián)刪除等。與WebLogic特性相關的技巧有:使用自動生成主鍵,WebLogic為Oracle和Sqlserver兩種數(shù)據(jù)庫的CMP提供了自動生成主鍵功能,節(jié)約了Entity Bean產(chǎn)生主鍵的時間,同時設key-cache-size不小于100;WebLogic管理事務性能更好,使用容器管理,而不是Bean管理事務; WebLogic提供了為CMP動態(tài)查詢和批量插入功能,對性能也有很大幫助。1.5.3 緩存資源對SLSB或者MDB來說,使用setMesssageDrivenContext()或者ejbCreate()方法緩存特定資源,在 ejbRemove()方法里釋放; 對SLSB或者MDB來說,使用setSessionContext()或者ejbCreate()方法緩存特定資源,在ejbRemove()方法里釋放;對Entity Bean來說,使用setEntityContext ()方法緩存特定資源,在unSetEntityContext ()方法里釋放。1.5.4 如何選擇和使用Entity Bean1. 在設計EJB時，要適當考慮EJB的粒度, 細粒度的EJB在事務管理和資源管理的開銷太大,盡量創(chuàng)建粗粒度的 EJB , 不要太粗，粗到能滿足實際需求就可以;2. Entity Bean不是唯一方式,如果只有一個很小的數(shù)據(jù)子集被經(jīng)常改變，建議采用JDO;3. 在操作大數(shù)據(jù)量的時候,直接采用JDBC比Entity Bean更有效;4. 避免采用返回很大數(shù)據(jù)組的finder方法,如 FindAll() 方法，因為它的實現(xiàn)代價太大;5. 考慮設置域組field groups,減少沒有必要并昂貴的屬性加載,如BLOB;6. 對于EJB1.1或者BMP,可以設置is-modified-method-name屬性,根據(jù)isModified()的值來判斷是否調(diào)用ejbStore()等方法,減少沒有必要運算;7. 避免連接多個表創(chuàng)建BMP,可以使用視圖,存儲過程或者O/R Mapping等方式。1.5.5 其他的一些小技巧1. 考慮使用 javax.ejb.SessionSynchronization 接口,提供在Rollback之后恢復數(shù)據(jù)的方法: afterBegin(), beforeCompletion(), afterCompletion();2. 使用完SFSB之后，調(diào)用remove()方法釋放實例;3. 假如你不需要EJB服務的時候,建議使用普通Java類;4. 避免EJB之間相互調(diào)用;5. 使用多讀模式。第二章 應用服務器調(diào)優(yōu)2.1 JVM調(diào)優(yōu)2.1.1 垃圾收集和堆大小垃圾收集(GC)是指JVM釋放Java堆中不再使用的對象所占用的內(nèi)存的過程,而Java堆(Heap)是指Java應用程序?qū)ο笊娴目臻g。堆大小決定了GC的頻度和時間。堆越大,GC頻度低,速度慢。堆越小,GC頻度高,速度快。所以GC和堆大小是一組矛盾。為了獲取理想的Heap堆大小,需要使用-verbosegc參數(shù)(Sun jdk: -Xloggc:)以打開詳細的GC輸出。分析GC的頻度和時間,結合應用最大負載所需內(nèi)存情況,得出堆的大小。通常情況下,我們建議使用可用內(nèi)存(除操作系統(tǒng)和其他應用程序占用之外的內(nèi)存)70-80%,為避免堆大小調(diào)整引起的開銷,設置內(nèi)存堆的最小值等于最大值即:- Xms=-Xmx。而為了防止內(nèi)存溢出,建議在生產(chǎn)環(huán)境堆大小至少為256M(Platform至少512M),實際環(huán)境中512M1G左右性能最佳, 2G以上是不可取的,在調(diào)整內(nèi)存時可能需要調(diào)整核心參數(shù)進程的允許最大內(nèi)存數(shù)。對于sun和hp的jvm,永久域太小(默認4M)也可能造成內(nèi)存溢出,應增加參-XX:MaxPermSize=128m。建議設置臨時域-Xmn的大小為-Xmx的1/41/3, SurvivorRatio為8。為了獲得更好的性能,建議在啟動文件設置WebLogic為產(chǎn)品模式,此時sun和hp jvm JIT引擎為-server,默認情況下打開JIT編譯模式對性能也有幫助。調(diào)整Chunk Size和Chunk Pool Size也可能對系統(tǒng)的吞吐量有提高。此外還需關閉顯示GC: -XX:+DisableExplicitGC。當然在Intel平臺上使用jRockit（使用參數(shù)-jrockit）無疑大大提高WebLogic性能。2.1.2 jRockit調(diào)優(yōu)jRockit支持四種垃圾收集器：分代復制收集器、單空間并發(fā)收集器、分代并發(fā)收集器和并行收集器。默認狀態(tài)下，JRockit使用分代并發(fā)收集器。要改變收集器，可使用-Xgc:,對應四個收集器分其他為gencopy, singlecom, gencon以及parallel。為得到更好的響應性能，應該使用并發(fā)垃圾回收器：-Xgc:gencon，可使用-Xms和-Xmx設置堆棧的初始大小和最大值,要設置護理域-Xns為-Xmx的10%。而如果要得到更好的性能，應該選用并行垃圾回收器:-Xgc: parallel，由于并行垃圾回收器不使用nursery，不必設置-Xns。如果你的線程大于100或者在linux平臺下，可以嘗試使用瘦線程模式：-Xthinthread,同時關閉Native IO:-Xallocationtype:global。jRockit 還提供了強大的圖形化監(jiān)控工具Jrockit Management Console。欲詳細了解JRockit可訪問：/wljrockit/docs81/index.html。2.2 Server調(diào)優(yōu)WebLogic Server的核心組件由監(jiān)聽線程,套接字復用器和可執(zhí)行線程的執(zhí)行隊列組成。當服務器由監(jiān)聽線程接收到連接請求后,將對它的連接控制權交給等待接收請求的套接字復用器。然后套接字復用器讀取離開套接字的請求,并將此請求及相關安全信息或事務處理環(huán)境一起置入適當?shù)膱?zhí)行隊列中(一般為默認的執(zhí)行隊列)。當有一個請求出現(xiàn)在執(zhí)行隊列中時，就會有一個空閑的執(zhí)行線程從該隊列中取走發(fā)來的該請求，并返回應答，然后等待下一次請求。因此要提高WebLogic的性能,就必須從調(diào)整核心組件性能出發(fā)。2.2.1 盡量使用本地I/O庫WebLogic Server有兩套套接字復用器：Java版和本地庫。采用小型本地庫更有效,盡量激活Enable Native IO(默認),此時UNIX默認使用CPUs+1個線程,Window下為雙倍CPU。如果系統(tǒng)不能加載本地庫,將會拋出 java.lang.UnsatisfiedLinkException,此時只能使用Java套接字復用器,可以調(diào)整socket readers 百分比,默認為33%。該參數(shù)可以在Console Server Tuning Configuration配置欄里設置。2.2.2 調(diào)整默認執(zhí)行線程數(shù)理想的默認執(zhí)行線程數(shù)是由多方面的因素決定的,比如機器CPU性能、總線體系架構、I/O、操作系統(tǒng)的進程調(diào)度機制、JVM的線程調(diào)度機制。 WebLogic生產(chǎn)環(huán)境下默認的線程為25個,隨著CPU個數(shù)的增加,WebLogic可以近乎線性地提高線程數(shù)。線程數(shù)越多，花費在線程切換的時間也就越多,線程數(shù)越小,CPU可能無法得到充分利用。為獲取一個理想的線程數(shù),需要經(jīng)過反復的測試。在測試中,可以以25*CPUs為基準進行調(diào)整。當空閑線程較少,CPU利用率比較低時,可以適當增加線程數(shù)的大小(每五個遞增)。對于PC Server 和Window 2000，則最好每個CPU小于50個線程, 以CPU利用率為90%左右為佳。由于目前WebLogic執(zhí)行線程沒有縮小線程數(shù)的功能,所以應將參數(shù)Threads Increase設置為0,同時不應改變優(yōu)先級的大小。2.2.3 調(diào)整連接參數(shù)WebLogic Server用Accept Backlog參數(shù)規(guī)定服務器向操作系統(tǒng)請求的隊列大小，默認值為50。當系統(tǒng)重載負荷時,這個值可能過小,日志中報Connection Refused,導致有效連接請求遭到拒絕,此時可以提高Accept Backlog 25%直到連接拒絕錯誤消失。對于Portal類型的應用,默認值往往是不夠的。Login Timeout和SSL Login Timeout參數(shù)表示普通連接和SSL連接的超時時間,如果客戶連接被服務器中斷或者SSL容量大,可以嘗試增加該值。這些參數(shù)可以在Console Server Tuning Configration配置欄里找到。2.2.4 創(chuàng)建新的執(zhí)行隊列創(chuàng)建新的執(zhí)行隊列有助于解決核心業(yè)務優(yōu)先、避免交叉阻塞、死鎖和長時間處理的業(yè)務等問題。通常會將自己的執(zhí)行隊列和默認的執(zhí)行隊列設置不同的優(yōu)先級, 這里優(yōu)先級不應設為9或者10。 定義一個新的執(zhí)行隊列很容易,利用View Excute Queue選項中的Configure a new Excute Queue鏈接即可定制新的執(zhí)行隊列。創(chuàng)建新的執(zhí)行隊列后，用戶需要為應用程序的J2EE組件配置分配策略，以便它可以找到新的隊列。舉個例子：要將 servlet或jsp捆綁到一個特定的執(zhí)行隊列，必須替換web.xml文件項，將wl-dispatch-policy初始化參數(shù)設置為自己的執(zhí)行隊列名。servletname/directoryname/deployment.jspwl-dispatch-policyNewExecuteQueueName我們可以為一個jsp或者servlet乃至一個WEB應用設置自己的執(zhí)行隊列。同時也可以為EJB設置自己的執(zhí)行隊列。對于執(zhí)行時間比較長的MDB,建議使用自己的執(zhí)行隊列。2.3 JDBC調(diào)優(yōu)2.3.1 調(diào)整連接池配置JDBC Connection Pool的調(diào)優(yōu)受制于WebLogic Server線程數(shù)的設置和數(shù)據(jù)庫進程數(shù),游標的大小。通常我們在一個線程中使用一個連接,所以連接數(shù)并不是越多越好,為避免兩邊的資源消耗，建議設置連接池的最大值等于或者略小于線程數(shù)。同時為了減少新建連接的開銷,將最小值和最大值設為一致。增加Statement Cache Size對于大量使用PreparedStatement對象的應用程序很有幫助,WebLogic能夠為每一個連接緩存這些對象,此值默認為10。在保證數(shù)據(jù)庫游標大小足夠的前提下,可以根據(jù)需要提高Statement Cache Size。比如當你設置連接數(shù)為25,Cache Size為10時,數(shù)據(jù)庫可能需要打開25*10=250個游標。不幸的是,當遇到與PreparedStatement Cache有關的應用程序錯誤時,你需要將Cache Size設置為0。盡管JDBC Connection Pool提供了很多高級參數(shù),在開發(fā)模式下比較有用,但大部分在生產(chǎn)環(huán)境下不需調(diào)整。這里建議最好不要設置測試表, 同時Test Reserved Connections和Test Released Connections也無需勾上。當然如果你的數(shù)據(jù)庫不穩(wěn)定,時斷時續(xù),你就可能需要上述的參數(shù)打開。 最后提一下驅(qū)動程序類型的選擇,以Oracle為例, Oracle提供thin驅(qū)動和oci驅(qū)動,從性能上來講,oci驅(qū)動強于thin驅(qū)動,特別是大數(shù)據(jù)量的操作。但在簡單的數(shù)據(jù)庫操作中,性能相差不大, 隨著thin驅(qū)動的不斷改進,這一弱勢將得到彌補。而thin驅(qū)動的移植性明顯強于oci驅(qū)動。所以在通常情況下建議使用thin驅(qū)動。而最新驅(qū)動器由于 WebLogic server/bin目錄下的類包可能不是最新的,請以Oracle網(wǎng)站為準: /technology/software/tech/java/sqlj_jdbc/htdocs/jdbc9201.html。2.4 WEB調(diào)優(yōu)2.4.1 調(diào)整WEB應用描述符WEB應用除代碼之外的調(diào)優(yōu)比較簡單,僅僅是對一些WEB應用描述符的調(diào)整。首先關閉Session Monitoring Enabled,僅僅在Cluster環(huán)境下設置Session復制(優(yōu)先使用內(nèi)存復制),在保證應用正常運行的情況下,設置較短的Session超時時間。 同時生產(chǎn)環(huán)境下無需檢查Jsp和servlet：JSPPage Check Secs和Servlet Reload Check Secs均設為-1,關閉JSPKeep Generated 和JSPVerbose對性能也有幫助。此外，還可以對jsp進行預編譯,有兩種方法：激活precompile選項；使用weblogic.appc事先編譯，建議采用后者。2.5 JMS調(diào)優(yōu)1. 增加-Dweblogic.JMSThreadPoolSize=n(至少為5),以提高處理JMS的線程數(shù),在jRockit上增加-XXenablefatspin以減少加鎖沖突;2. 采用文件存儲策略,將同步寫策略設置為Direct-Write,同時在windows平臺上啟用磁盤寫入緩存;3. 使用分布式目的地時,激活連接工廠Load Balancing Enabled ,Server Affinity Enabled;4. 為減少服務器不必要的JMS請求路由,如果多個目的地之間存在事務,則部署在同一JMS服務器上,盡量將連接工廠部署到JMS服務器所在的 WebLogic實例上,集群環(huán)境下，則最好將連接工廠部署到集群中的所有服務器上,而集群中每個JMS服務器和目的地成員盡量使用類似的設置；5. 啟用消息分頁存儲功能,以釋放內(nèi)存,可以為JMS服務器和目的地設置, 激活Messages Paging Enabled和Bytes Paging Enabled,同時使用限額防止服務器耗盡接收消息的所有可用內(nèi)存空間;6. 在運行WebLogic Server進程之外的生產(chǎn)者務必使用流控制, 并增大Send Timeout;7. 將JMS Server Expiration Scan Interval設很大的值，能禁止主動掃描過期消息;8. 使用FIFO或者LIFO方式處理目的地消息;9. MDB的max-beans-in-free-pool不應大于最大MDB線程數(shù)(默認線程數(shù)/2+1)。 2.6 EJB調(diào)優(yōu)2.6.1 調(diào)整pool和cache initial-beans-in-free-pool定義SLSB啟動時實例的個數(shù),默認為0,可以調(diào)大到正常并發(fā)數(shù)的大小,以減少初始響應時間。 max-beans-in-free-pool為最大個數(shù),默認1000對SLSB來說,在頻繁創(chuàng)建和刪除實例的情況下很有幫助,一般不用調(diào)整,至少設為默認線程數(shù),過大容易造成內(nèi)存溢出。而對Entity Bean來說,由于是匿名的,所以當頻繁使用finder、home和create方法時可以調(diào)大。對SFSB來說,盡量將max- beans-in-cache參數(shù)設置得足夠的大，以滿足Bean實例對最大并發(fā)用戶數(shù)的要求，可以避免有狀態(tài)會話Bean過多的鈍化行為。而idle- timeout-seconds盡量設置小,如果SFSB不用于存儲Web應用會話狀態(tài)可以設置為0。對于Entity Bean來說, max-beans-in-cache同樣可以首先采用默認值1000，監(jiān)控實例緩存和鈍化的情況,再做適當調(diào)整。并行策略concurrency-strategy定義了實體Bean如何管理鎖,有四種策略: Exclusive、Databse、ReadOnly、Optimistic。效率依次提高,可靠性依次降低,盡量避免使用互斥策略,如果Bean無需更新操作,使用只讀策略,更甚的是,如果Bean的內(nèi)容不會改變,可設置read-timeout-seconds為0,樂觀并行策略時采用事務間緩存策略,在entity-cache描述符中將cache-between-transactions元素設為true。2.6.2 優(yōu)化事務隔離級別和事務屬性對EJB組件來說，有四種事務隔離水平：TRANSACTION-SERIALIZABLE：在處理完成之前拒絕其他處理的讀入、可擴展性或插入數(shù)據(jù)操作; TRANSACTION-REPEATABLE-READ：防止處理修改正在被其他處理調(diào)用的數(shù)據(jù); TRANSACTOIN-READ-COMMITTED：防止對正在被其他處理修改的數(shù)據(jù)執(zhí)行寫鎖定； TRANSACTION-READ-UNCOMMITTED：允許處理讀入未受權的數(shù)據(jù)以及允許在向結果中添加記錄時可以忽略處理。 以上隔離水平依次降低,效率和性能依次提高。因此,建議選用滿足在業(yè)務數(shù)據(jù)完整性要求前提下水平最低的隔離級別。對于事務屬性的設置也是如此,對于刪除、修改和插入操作設置為Required,而對于只讀操作設置為Supports或者NotSupports。2.6.3 其他一些小技巧1. 利用finders-load-bean的默認值true，既可以避免“n+1”的查詢問題，又可以提高系統(tǒng)的性能;2. 使用delay-updates-until-end-of-tx參數(shù)的默認值true，除非應用程序?qū)δ承┳兓刑貏e的要求;3. 應用程序在每個業(yè)務方法調(diào)用后不需要進行存在性檢查，將check-exists-on-method設定為false，以提高程序的性能;4. 同一應用內(nèi), 將enable-call-by-reference設置為 true;5. reentrant設置為false,避免事先加載子數(shù)據(jù)。第三章 數(shù)據(jù)庫調(diào)優(yōu)3.1.1 Oracle性能優(yōu)化Oracle9i的性能優(yōu)化除了調(diào)整kernal之外就是主要對Oracle啟動文件的調(diào)整,即調(diào)整SGA的參數(shù)。注意,不同操作系統(tǒng)不同位數(shù)的機器最優(yōu)的參數(shù)不是一樣的,這里主要有windows和unix之分,32位和64位之分。首先需要調(diào)大進程數(shù)和游標數(shù),一般默認的值對實際應用來說都比較小,比如說,進程數(shù)可以調(diào)到300,游標數(shù)可以調(diào)到500。其次,看一個經(jīng)驗公式: OS 使用內(nèi)存+ SGA + session*(sort_area_size + hash_area_size +2M)0.7RAM,通常認為此時的SGA比較合理。這里sort_area_size為64k, hash_area_size為128k(當排序多的時候需要增大sort_area_size,按調(diào)整后的值計算),session表示最大并發(fā)進程數(shù),假設100個。假如1G內(nèi)存的機器,OS占用200M,PGA占用200M左右,那么SGA可以設為400-500M，如果2G內(nèi)存可以1G給 SGA，8G可以5G給SGA。不過對于32位數(shù)據(jù)庫來說，通常最多只能使用1.7G內(nèi)存。然后，SGA內(nèi)參數(shù)設置的基本原則是： data buffer 通?？梢员M可能的大，shared_pool_size 要適度，log_buffer 通常大到幾百K到1M就差不多。具體的：data buffer 1G內(nèi)存可以設置500M，2G設為1.2G，8G可設為5G 。shared_pool_size不易過大，通常應該控制在200M-300M,如果使用了大量的存儲過程，可以根據(jù)SGA的值增大到500M，如果增大后命中率得不到提高，則增加是無益的。具體的：1G內(nèi)存可以設置100M，2G設為150M，8G可設為300M。如不使用Java， java_pool_size 10-20M即可。large_pool_size如果不設置MTS，在20M -30M 即可，假如設置 MTS,可以考慮為 session * (sort_area_size + 2M)。最后，關于內(nèi)存的設置可根據(jù)statspack信息和v$system_event,v$sysstat,v$sesstat,v$latch 等view信息來考慮微調(diào)。3.1.2 Oracle的其他調(diào)整為了Oracle高效率的運行，除了上面提到的內(nèi)存因素之外，還有就是需要良好的數(shù)據(jù)庫設計：表、視圖、索引和日志的合理規(guī)劃和建立。I/O的性能也是重要因素，應盡量減少頁交換和頁分配。此外，就是改善檢查點的效率。第四章 操作系統(tǒng)調(diào)優(yōu)4.1 操作系統(tǒng)調(diào)整操作系統(tǒng)影響應用程序運行性能的因素主要有：硬件的配置(CPU、內(nèi)存、硬盤等),核心參數(shù),TCP/IP參數(shù)以及補丁的情況等。這里對操作系統(tǒng)的優(yōu)化,除了更新最新的補丁程序以保證應用程序正常運行之外,就是調(diào)整TCP/IP參數(shù),文件描述符,對于個別操作系統(tǒng)還有其他特別的參數(shù)調(diào)整。下面將依次介紹不同操作系統(tǒng)的情況,更多的信息請參考各操作系統(tǒng)的文檔。4.1.1 HP-UX對于HP-UX,你首先需要安裝Java Patch:/products1/unix/java/patches/index.html,然后需要確認下面文檔中的核心參數(shù)是否滿足(可以使用sam命令修改核心參數(shù)):/platform/suppconfigs/configs81/hpux11_risc/81sp3.html#80105。調(diào)整TCP參數(shù): ndd -set /dev/tcp tcp_conn_req_max 1024, 將偵聽隊列的最大允許長度調(diào)整到1024。 有時操作系統(tǒng)限制進程使用的最大內(nèi)存數(shù)小于你要配置的內(nèi)存大小,則需要調(diào)整該值。讀者可以從/hpux/onlinedocs/TKP-90203/TKP-90203.html了解更多的HP-UX調(diào)整建議。4.1.2 Solaris調(diào)整TCP的參數(shù),等待時間間隔tcp-time-wait-interval建議設置為60000ms: /usr/sbin/ndd ?set /dev/tcp tcp_time_wait_interval 60000;其他參數(shù)調(diào)整如下:tcp_xmit_hiwat/tcp_recv_hiwat 131072tcp_conn_req_max_q/tcp_conn_req_max_q0 16384調(diào)整一個進程打開的文件描述符的數(shù)量:軟限制和硬限制以及散列表的大小,修改/etc/system文件:set tcp:tcp_conn_hash_size=32768set rlim_fd_cur=8192set rlim_fd_max=8192更多的調(diào)整信息請查閱: /db/doc/806-7009(Solaris9)。4.1.3 AIXAIX用no命令調(diào)整TCP參數(shù)，等待時間間隔tcp_timewait: no -o tcp_timewait=4,將tcp.timewait參數(shù)設置為4個15秒間隔，即1分鐘。運行no -a命令將顯示網(wǎng)絡當前的所有屬性值。由于UDP_SENDSPACE默認的緩存大小是8k,為減少I/O異常,需調(diào)整為32k:no -o udp_sendspace=32768。此外, 當WebLogic HTTP請求忙時,可以調(diào)整偵聽隊列的最大長somaxconn到8192(默認值是1024)。更多信息:/pseries/en-us/aixbman/prftungd/prftungd.htm。4.1.4 Linux調(diào)整Linux系統(tǒng)使用sysctl命令修改TCP參數(shù)等待時間間隔:sysctl -w ip_ct_tcp_timeout_time_wait=60;調(diào)整打開文件的最大數(shù):在/etc/sysctl.conf文件中，添加: Fs.file-max=65535,然后運行sysctl -p;調(diào)整打開文件描述符最大數(shù)為8192:在/etc/security/limits.conf文件，添加:WebLogic hard nofile 8192(僅針對WebLogic用戶),然后在WebLogic啟動文件里運行ulimit-n 8192激活設置。更多信息請查閱:/ipsysctl-tutorial.html。4.1.5 WindowsWindows系統(tǒng)的調(diào)整通過修改注冊表HKEY-LOCAL-MACHINESYSTEMCurrent ControlSetServices文件夾來完成?？梢哉{(diào)整TcpipParameters子文件夾中的等待時間間隔時間 TcpTimedWaitDelay參數(shù)的值。偵聽隊列最大長度的默認值為15，為修改它，可在InetinfoParameters子目錄中創(chuàng)建 DWORD條目ListenBackLog。此外,Windows2000的Service Pack(要求sp3以上)也會影響系統(tǒng)穩(wěn)定性: /platform/suppconfigs/configs81/win2ksvr_as_data_pentium/81sp3.html。第五章 性能監(jiān)控和性能分析5.1 性能瓶頸最后,介紹一下實際分析J2EE應用性能的常用命令和工具。對于實現(xiàn)一個高性能的J2EE應用來說,掌握了J2EE調(diào)優(yōu)的理論經(jīng)驗還是不夠的。掌握性能監(jiān)控,發(fā)現(xiàn)瓶頸和問題診斷才是保證J2EE系統(tǒng)持續(xù)高效運行的關鍵。瓶頸指的是限值所有吞吐操作以及嚴重影響反應時間的系統(tǒng)內(nèi)資源。在分布式系統(tǒng)內(nèi)尋找并糾正瓶頸是非常困難的，需要有經(jīng)驗的團隊來解決。瓶頸會發(fā)生在Web 服務器上，程序代碼中，應用服務器上，數(shù)據(jù)庫，操作系統(tǒng)或者網(wǎng)絡，硬件上。經(jīng)驗表明，瓶頸很容易發(fā)生在如下地方：數(shù)據(jù)庫連接與隊列中；應用服務器的程序代碼中；應用服務器和Web服務器硬件上；網(wǎng)絡和TCP配置中。實際中可以著力對這些環(huán)節(jié)進行監(jiān)控。5.2 操作系統(tǒng)監(jiān)控操作系統(tǒng)層面的性能監(jiān)控主要是對內(nèi)存、CPU、I/O和交換區(qū)的使用情況進行監(jiān)控分析。windows平臺可以通過任務管理器和perfmon工具查看。如果是unix系統(tǒng)可以使用stat系列命令(vmstat, mpstat, iostat)監(jiān)控內(nèi)存、CPU和I/O的即時變化,使用swap命令查看交換區(qū)的使用情況。如果操作系統(tǒng)安裝了top、topas、glance等使用工具,則使用top、topas、glance將能更為方便地看到WebLogic進程對操作系統(tǒng)的內(nèi)存,CPU和I/O資源使用的即時變化情況。而網(wǎng)絡方面的性能可以通過ping和netstat等命令來監(jiān)控,主要幾個關鍵的網(wǎng)絡統(tǒng)計值,如數(shù)據(jù)包再發(fā)送、重復數(shù)據(jù)包和數(shù)據(jù)包偵聽丟失。說明:本文提到的unix命令并非適用所有操作系統(tǒng),僅供參考。5.3 數(shù)據(jù)庫監(jiān)控數(shù)據(jù)庫層面的監(jiān)控這里為oracle9i為例來說明,可以采用oracle自帶的工具Oracle Interprise Manager Console來監(jiān)控session和sql的執(zhí)行情況。還有其他專業(yè)的數(shù)據(jù)庫監(jiān)控工具可以使用,比如QUEST的spotlight(/spotlight-portal/)可以非常形象和直觀地對Oracle數(shù)據(jù)庫的CPU、內(nèi)存、I/O、Data Buffer Size、Shared Pool Size、Redo Buffer等參數(shù)進行即時監(jiān)控,并自動對不正常的參數(shù)以紅色顯示。5.4 WebLogic監(jiān)控5.4.1 JVM監(jiān)控采用java參數(shù)-verbose:gc 來分析JVM的GC非常繁瑣，而且不直觀。使用-Xloggc:gc.log 參數(shù)將GC日志寫入文件,采用GC 工具HPjtune (/tools/hpjtune/index.shtml)進行