一切皆可抽象

HBCZT信息中心使用 IBM X366 服務器 Windows2003 運行其基于 J2EE1.4 技術的應用系統。另外運行一個基于 COM 技術的數據采集應用程序。該程序客戶端讀入用戶填寫的 xls 格式表格文件信息，并通過該程序將 XLS 內容封裝成為 XML 并打包 ZIP 后發送到數據采集程序的服務器端，服務器端接受到文件后，對該 ZIP 包進行解包、并對解包后的 XML 信息進行解析、使用 SQL 逐條將記錄插入到 Oracle 數據庫中。數據庫連接池已經設置為 20 ，但批量數據插入數據庫的時候（數據量至少 500000 條記錄，一般情況 5000000 條記錄）導致數據庫異常緩慢。客戶希望找到系統瓶頸，并提出相應性能調優建議。

l ??????? 總體思路

硬件調優、操作系統調優，數據庫調優 略！我們假設都已經是最佳狀態。由于本人負責 WebLogic 部分的調優，所以以下思路與內容均為 WebLogic 方面。特此說明

J2EE 應用架構環境下的系統調優，首先我們一般會從應用程序出發，去審核代碼，做到代碼級的優化，然后再調整應用服務器 (BEA WebLogic8.1) 和數據庫 (Oracle9i) 的參數，最后當然是調整操作系統和網絡的性能 ( 包括硬件升級 ) 。這是一種 MDA 的先進做法。誠然，在這樣一個政務項目中，不可能完全按照這個思路來做，我們把目標首先定位在應用系統所在的應用服務器 (BEA WebLogic8.1) 上，通過對 BEA WebLogic8.1 的參數進行設置，使 WebLogic8.1 能夠在最優化的環境中去運行其系統，然后對 ORACLE 數據的參數進行優化設置，最后進行性能測試再找出導致性能瓶頸所在的 SQL 代碼或 JAVA 程序，考量其修改的可行性，并進行最終問題優先級認定，與瓶頸模塊進行協商解決性能問題。當然，一般情況下我見過的案例都是出現了性能問題后才想到調優，而且一般都是先進行系統參數調整，實在解決不了才會對代碼進行檢查 . 實際上，我們應當將代碼級的調優放在應用設計時來做，測試生產時修改代碼將是一件極其痛苦的事情。

下表為一般性 J2EE 性能調優的參照情況一覽表，供參考。

?

l ??????? 調優建議

通過分析其配置。我們發現 JDBC 連接池存在性能問題。

在 WebLogic 中就大量使用了池 :JDBC Connection Pool 、 Socket Pool 、 Object Pool 和 Thread Pool 。 I/O 操作中， buffer 是必須的，特別是對大文件的操作，不然容易造成內存溢出。字節操作最快，所以盡可能采用 write(byte[]) ， Buffered FileOutputStream 比 Buffered FileWriter 要快，因為 FileWriter 需要 Unicode 到 Byte 的轉換。 JDBC 建議使用 buffer 和 cache 。為 HttpServletResponse 設置 buffersize ，使用 wl-cache ，緩存在 JNDI 樹上獲取的對象等等。
　　此外，使用 JDK 1.4 的非阻塞 I/O 對性能也有很大提高。
　　 JDBC 代碼調優最大的原則就是使用 WebLogic 的連接池，而不是自己直連數據庫。在我接觸的很多自己實現連接池的項目中，大部分遇到死鎖和連接泄漏的問題，最后得不得修改代碼。而 WebLogic 提供了功能強大，性能良好的數據庫連接池，我們要做的只是封裝一個連接管理類，從 JNDI 樹上獲取數據源并緩存，得到連接，并提供一系列關閉數據庫資源的方法。

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

由于獲取連接時默認自動提交方式，使用 connection.setAutoCommit(false) 關閉自動提交，使用 PreparedStatement ，批量更新，業務復雜或者大數據量操作時使用存儲過程，盡量使用 RowSet ，此外設置記錄集讀取緩存 FetchSize 和設置記錄集讀取方向 FetchDirection 對性能也有一定的提高。

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

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 也無需勾上。 當然如果你的數據庫不穩定，時斷時續，你就可能需要上述的參數打開。

最后分析一下 JDBC 驅動程序類型的選擇， Oracle 提供 thin 驅動和 oci 驅動，從性能上來講， oci 驅動強于 thin 驅動，特別是大數據量的操作。但在簡單的數據庫操作中，性能相差不大。所以我建議對數據量至少 500000 條記錄，一般情況 5000000 條記錄的狀況使用 oci 驅動。

通過分析其日志并使用 GC 資源查看。我們發現存在內存泄露的垃圾回收失敗問題。

垃圾收集 (GC) 是指 JVM 釋放 Java 堆中不再使用的對象所占用的內存的過程，而 Java 堆 (Heap) 是指 Java 應用程序對象生存的空間。堆大小決定了 GC 的頻度和時間。堆越大， GC 頻度低，速度慢。堆越小， GC 頻度高，速度快。所以 GC 和堆大小是一組矛盾。為了獲取理想的 Heap 堆大小，需要使用 -verbosegc 參數 (Sun jdk: -Xloggc:) 以打開詳細的 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 性能。本系統使用 SUN JDK1.4.2_08 。 jRockit 支持四種垃圾收集器：分代復制收集器、單空間并發收集器、分代并發收集器和并行收集器。默認狀態下， JRockit 使用分代并發收集器。要改變收集器，可使用 -Xgc: ，對應四個收集器分其他為 gencopy ， singlecom ， gencon 以及 parallel 。為得到更好的響應性能，應該使用并發垃圾回收器： -Xgc:gencon ，可使用 -Xms 和 -Xmx 設置堆棧的初始大小和最大值，要設置護理域 -Xns 為 -Xmx 的 10% 。而如果要得到更好的性能，應該選用并行垃圾回收器 :-Xgc: parallel ，由于并行垃圾回收器不使用 nursery ，不必設置 -Xns 。 jRockit 還提供了強大的圖形化監控工具 Jrockit Management Console ?？梢圆榭?/font> GC 性能問題。