WebLogic 配置文件(config.xml)包含了大量很直觀的與性能有關的參數,能通過配置環境與應用程序得到很好的優化。基於系統的需要調整這些參數不僅能改善單個點的性能,而且能提高整個應用程序性能的可衡量性。
元素
|
屬性
|
控制檯標籤
|
備註
|
Server
|
NativeIOEnabled
|
Native IO Enabled
|
|
ExecuteQueue
|
ThreadCount
|
Thread Count
|
|
ExecuteQueue
|
QueueLength
QueueLengthThresholdPercent
ThreadsIncrease
ThreadsMaximum
ThreadPriority
|
Queue Length
Queue Length Threshold Percent
(隊列長限度百分比)
Threads Increase
Threads Maximum
Thread Priority
|
|
Server
|
StuckThreadMaxTime
StuckThreadTimerInteral
|
Stuck Thread Max Time
(堵塞線程的最長時間)
Stuck Thread Timer Interval
(堵塞線程的時間間隔)
|
|
Server
|
ThreadPoolPercentSocketReaders
|
Socket Readers
|
|
Server
|
AcceptBacklog
|
Accept Backlog
(接受緩存數)
|
|
JDBCConnectionPool
|
InitialCapacity
MaxCapacity
|
Initial Capacity
Max Capacity
|
|
JDBCConnectionPool
|
StatementCacheSize
|
Statement Cache Size
(聲明高速緩衝大小)
|
優化參數
|
開發模式
|
產品模式
|
Execute Queue: ThreadCount
|
15 threads
|
25 threads
|
JDBC Connection Pool: MaxCapacity
|
15 connections
|
25 connections
|
功用名稱
|
開發模式
|
產品模式
|
SSL
|
你可以使用 WebLogic 安全服務提供的驗證數字證書。有這些證書,你開發的應用程序會在 SSL 保護的環境下運行。
|
如果你使用驗證數字證書,會收到警告信息。
|
部署應用程序
|
WEBLOGIC 實例會自動部署和更新位於 domain_name/applications 目錄下的應用程序( domain_name 爲域的名稱)。
|
不能使用自動部署功能,必須使用 WebLogic 控制檯或者 WebLogiceblogic Deployer 工具。
|
Log File Rotation
|
啓動服務器後,服務器自動重命名本地日誌文件爲 server-name.log.n ,爲了滯留的 session ,只要日誌文件的達到 500kb ,日誌文件就會滾轉一次。
|
當日志文件達到 500kb ,就會滾轉。
|
Execute Queues
|
默認的執行線程爲 15 。
|
默認的執行線程爲 25 。
|
JDBC Connection Pool Capacity
|
默認的容量爲 15 。
|
默認的容量爲 25 。
|
如果…
|
結果
|
應該:
|
線程數<CPU的數量
|
線程數太少,如果:
CPU 正等着工作,但有工作被完成。
CPU 利用率不能達到100%。
|
增加線程數。
|
線程數=CPU的數量
|
理論上理想,但是CPU仍然低利用。
|
增加線程數。
|
線程數(適當的)>CPU的數量
|
實際中理想,有個適當的上下文轉換程序數量和高的CPU利用率。
|
調整適當的線程數並且比較性能結果。
|
線程數(較大的)>CPU的數量
|
過多的上下文轉換程序,能導致重大的性能降級。
當你降低線程數時,性能可以增強。
|
減少線程數,使它等於CPU的數量,然後僅僅增加已經得出的“堵塞”線程的數量。
例如,如果你有4個處理器,它們都同時運行,並出現堵塞線程,於是,你想要的執行線程就是4+堵塞線程的數
|
5 . 8 分配執行隊列擔任 Socket 讀
爲了獲得更好的 socket 性能, BEA 推薦你使用自有的 socket 讀執行工具,它更優於純 Java 執行工具。然而,如果你一定要在主機上用純 Java 的 socket 讀,你仍然可以通過配置恰當的執行線程數以提高 socket 通信性能,爲每個服務器實例和客戶機器擔負 socket 讀線程的任務。
Socket 讀佔線程池百分比( ThreadPoolPercentSocketReader )屬性可以設置用來從 socket 讀消息的執行線程的最大百分比。這個屬性的最優值是根據應用程序的需要指定的。默認值是 33 ,有效範圍在 1 - 99 之間。
分配執行線程擔任 socket 讀增加了服務器處理速度和接受客戶請求的能力。有必要平衡執行線程數,使其專注於從 socket 讀消息,也有必要平衡那些在服務器處理實際任務的執行線程。
5 . 9 爲服務器實例設置 socket 讀的線程數的操作
1 . 啓動管理服務器,訪問域控制檯。
2 . 展開左邊面板 Servers 節點,顯示域服務配置。
3 . 點擊你要配置的服務名稱。
4 . 選擇配置( Configuration )―― > 調整( Tuning )標籤。
5 . 在 Socket Reader 中編輯 Java 讀線程的百分比。 Java socket 讀線程數是根據所有的執行線程數的百分比計算得到的。
6 . 應用( Apply )這個調整。
5 . 10 在客戶機設置 Socket 讀線程數
在客戶機上,你可以配置運行在 JVM ( Java 虛擬機)上的 socket 讀線程數。指定 Socket 讀,需要通過用 java 命令行定義下列參數:
-Dweblogic.ThreadPoolSize=value
-Dweblogic.ThreadPoolPercentSocketReaders=value 5 . 11 優化溢出情況時的執行隊列
你可以配置 WEBLOGIC 監測並且隨時應對潛在的溢出,不管其發生在默認的執行隊列還是用戶定義的隊列。一旦當前隊列大小快達到用戶定義的百分比, WebLogic 認爲隊列中有一個可能的溢出產生。
當這個限度到達時,服務器改變它的良好狀態爲“警告”,隨即分配額外的線程去處理超負荷的工作,從而還原它的大小。
爲了自動監測和應對溢出,你可以配置以下項:
1 . 隊列長限制百分比,這個值是隊列大小的百分比。
2 . 當溢出發生時,增加到隊列的線程數。這些額外的線程以還原隊列到正常的運行的大小。
3 . 線程的最大數,在特殊情況下,線程最大數用來保護服務器在響應過載情況下過度分配線程數。
5 . 12 優化執行隊列的監測行爲
當一個線程在隊列中變成堵塞狀態時, WebLogic 會自動監測到。因爲堵塞線程不能完成它當前的工作或接受新的工作,服務器每次診斷一個堵塞線程,就記入一個消息到日誌中。如果一個隊列中所有的線程變成堵塞,服務器改變良好狀態成“警告”或者“危機”,依賴於下列情況:
n 如果默認隊列中所有的線程變成堵塞,服務器狀態變成“危機”。(你可以設立節點管理器( Node Manager )應用去自動關閉及重啓服務器。)
n 如果在 weblogic.admin.HTTP, weblogic.admin.RMI 或用戶定義的隊列中所有線程變成堵塞,服務器狀態變成“警告”。
WebLogic 診斷到一個堵塞線程,如果它是在指定的時間內連續不斷的工作(沒有空閒)。你可以調整服務器線程監測行爲,它是通過改變堵塞線程被診斷前的時間長度和服務器覈查堵塞線程的頻率。
注意:儘管你能改變標準 WebLogic 去決定一個線程是否堵塞,但,你不能改變默認行爲,就是出現堵塞時把服務器設置成“警告”或“危機”的行爲。
配置 WebLogic 堵塞線程監測行爲的步驟:
1 . 啓動 WebLogic ,訪問管理控制檯。
2 . 點擊你想爲改善堵塞線監測而修改的服務器實例的名稱。
3 . 選擇配置( Configuration )―― > 調整( Tuning )標籤。
4 . 修改下列參數:
n 堵塞線程最大時間( Stuck Thread Max Time ):輸入秒數,線程一定是不斷的運行,服務器纔會診斷這個線程作爲堵塞。默認情況下, WebLogic 認爲線程連續不斷運行 600 秒後置爲堵塞。
n 堵塞線程時間間隔( Stuck Thread Timer Interval ):輸入秒數,這個時間是 WebLogic 週期性的掃描線程以察覺它們是否連續不斷運行了某一線程的時間達到通過堵塞線程最大時間屬性指定的時間長度。默認時間間隔爲 600 秒。
5 . 應用( Apply )設置。
6 . 重啓服務器。
六、優化連接緩存
Config.xml 文件中的元素接受緩存數( AcceptBacklog )屬性是用來設定請求 WebLogic 實例的連接數,在拒絕額外的請求之前,能接受設定的緩存數。 AcceptBacklog 屬性指定有多少 TCP 連接緩存在等待隊列,這個固定的隊列存放了 TCP 堆棧已經收到但應用程序還沒有收到的連接請求。默認值是 50 ,最大值由操作系統決定。
在控制檯調整接受緩存數的步驟:
1. 啓動 WebLogic ,訪問控制檯。
2. 展開左邊面板 Servers 節點。
3. 點擊你要配置的服務器實例的名稱。
4. 選擇配置( Configuration )―― > 調整( Tuning )標籤。
5. 根據需要修改默認的接受緩存數( Accept Backlog ):
n 在運行期間,如果許多客戶端連接得不到響應或被拒絕,並且服務器端也沒有錯誤消息,說明接受緩存的值可能太小。
n 在你訪問 WebLogic 時,如果收到“拒絕連接( connection refused )”的提示,則應該增加接受緩存的默認值的 25 %。繼續增加其值的 25 %,直到停止出現這樣的提示。
6. 點擊應用( Apply ),保存設置。
七、如何提高 JDBC 連接池的性能
創建一個帶 DBMS 的 JDBC 連接是非常慢的。如果應用程序需要數據庫不斷的連接和斷開,這種創建方式會造成一個重大的性能問題。 WebLogic 連接池提供了一種高效的解決方案來解決這個問題。
當啓動 WebLogic ,就打開連接池,以便於所有客戶連接。當一個客戶關閉一個連接,這個連接就返回到連接池,供其他的客戶使用。連接本身不會關閉。如此就用極少的代價實現了連接和斷開連接池。
在連接池裏應該創建多少連接呢?連接池會根據配置參數中的最大數與最小數之間增加或減少連接。最好的性能應該是連接數與當前客戶會話( Session )數相同。
7 . 1 調整 JDBC 連接池的初始容量
在配置連接池時, JDBCConnectionPool 元素中的 InitialCapacity 屬性能設定連接數,創建物理的數據庫連接。如果服務器不能創建這個連接數,連接池的創建就會失敗。
在開發期間,爲了使服務器啓動更快,可以很方便的設置 InitialCapacity 屬性的值小一點。在產品系統中,就應該把 InitialCapacity 的值設爲與 MaxCapacity 值相同,默認產品模式的值爲 25 。這樣,在服務器啓動時,所有的連接就會被創建。如果你調整了 MaxCapacity 值後,一定要確信 InitialCapacity 值設置與 MaxCapacity 值相同。
如果 InitialCapacity 比 MaxCapacity 值少,當負荷增加時,服務器需要創建額外的數據庫連接。當服務器處於低負荷時,所有的資源應該是儘快的完成請求,而不是創建新的數據庫連接。
7 . 2 調整 JDBC 連接池的最大容量
JDBCConnectonPool 元素中的 MaxCapacity 屬性設置連接池包含的最大的物理數據庫連接數。不同的 JDBC 驅動程序和數據庫服務器可能限制物理連接數。
默認的最大容量數與默認的線程數相等:開發模式爲 15 ,產品模式爲 25 。不過,在產品模式下,建議連接數與當前的客戶會話( Session )數相等。在服務器端,連接池的容量與執行線程數是無關的,正在進行的用戶會話比執行線程更多。
八、設置 Java 編譯器
編譯 JSP Servlet 的標準 Java 編譯器是 javac 。你可以把 java 編譯器設置爲 si 或 jikes 代替 javac ,這樣能極大的提高性能。下面討論設置步驟及其要考慮的事項。
8 . 1 通過控制檯改變編譯器
1. 啓動服務器,訪問控制檯。
2. 展開左邊面板 Servers 節點。
3. 點擊要配置的服務器實例的名稱。
4. 選擇配置( Configuration )―― > 常規( General ),在 Java Compiler 編輯框輸入編譯器的完全路徑。如: c:\visualcafe31\bin\sj.exe
5. 點擊高級選項( Advanced Option )―― >Show ,顯示其他的屬性。
6. 用添加( Append )把完全路徑通過 Classpath 框輸入到 JRE rt.jar 庫。如:
BEA_HOME \jdk141_02\jre\lib\rt.jar
7. 點擊應用。
8. 重啓服務器。
8 . 2 在 Weblogic.xml 文件中設置編譯器
n 使用 compileCommand 參數指定 Java 編譯器。
n 使用 procompile 參數配置 WebLogic ,在啓動 WebLogic 時預編譯 JSP 。
8 . 3 編譯 EJB 容器類
使用 Weblogic.appc 的功能去編譯 EJB2.0 和 1.1 容器類。如果編譯 Jar 文件部署 EJB 容器,你必須使用 weblogic.appc 生成容器類。默認情況下, EJB 使用 javac 編譯器。爲了得到跟好的性能,使用- compiler 標誌指定不同的編譯器(如 Symantec 公司的 sj )
8 . 4 在 UNIX 環境下編譯
在 UNIX 機器上編譯 JSP 文件,如果收到下列錯誤消息:
failed : java.io.IOException:Not enough space
試試下列一些或所有的解決方法:
n 如果你只有 256MB 的內存,增加更大的內存。
n 提高文件描述文件的限制,如:
set rlim_fd_max=4096
set rlim_fd_cur=1024
n 啓動 JVM 時,用- native 標誌來使用自有的線程。
九、使用 WebLogic 集羣提高性能
WebLogic 集羣是指一組 WebLogic 實例在一起提供具有防過載和自有複製的功能,以用一個域爲所有客戶支持可伸縮的高可用性運行。集羣對於客戶是一個單一的服務器,但實際上是一組服務器來提高可靠性和可伸縮性。
9 . 1 可伸縮性和高的可用性
可伸縮性是系統增加一個或更多部件作爲系統資源的能力。很典型的是,這些部件使併發用戶得到支持,使併發事務能在特定的時間單位能被處理。
假定應用程序設計良好,它完全可以簡單的增加更多的資源來提高性能。爲了增加 WebLogic 處理的負荷量,只需增加一個 WebLogic 實例到你的集羣――不需改變應用程序。集羣提高兩個關鍵的好處:可伸縮性和可用性,這是單一服務器無法比擬的。
WebLogic 集羣給 J2EE 帶來了可伸縮性和高的可用性,而且對於應用程序的開發者是透明的。可伸縮性擴展了中間層的能力,超過了單一的 WebLogic 服務器或單一的計算機能處理的。集羣成員唯一的限制是所有 WebLogic 必須要用 IP 多點傳送通信。新的 WebLogic 能動態的增加到集羣,以增加處理能力。
WebLogic 集羣保證高的可用性是通過多個服務器的冗餘,減少客戶的請求失敗。集羣中多個服務器能提供同一服務。如果一個服務器停止運行,另一個能接替運行。這種功能爲客戶增加了可用性。
警告:如果你要解決應用程序和環境的頸瓶問題,增加額外的服務器到集羣,應該提供線性的可伸縮性。定基準和初始配置測試運行時,在移到集羣環境之前,應把應用隔離在單獨的服務器上測試。
9 . 2 在多 CPU 機器上運行多服務器實例,應考慮的性能問題
多處理器的機器上,必須考慮羣集 WebLogic 實例數應與 CPU 的數量成比例。因爲 WebLogic 沒有內置限制的服務器實例數位於集羣裏,規模大的、多處理器服務器,如 Sun 公司的 Sun Enterprise 10000 ,有着當作非常大的集羣或多集羣主機的潛能。
在決定最佳的服務器與 CPU 比例前,徹底測試你的應用程序並確定如下:
n 網絡要求 如果你發現 Web 應用程序是主要受網絡 I/O 限制,在增加 CPU 數前,考慮測試網絡的吞吐量。如果實際是網絡 I/O 限制,安裝一個更快的網絡接口卡( NIC )可以提供性能,而不是增加額外的 CPU ,因爲在等着讀 socket 時,更多的 CPU 會處於閒置。
n 磁盤 I/O 要求 如果你發現 Web 應用程序主要受磁盤 I/O 限制。在配置額外的 CPU 前,就應該考慮增加磁盤轉速或單個磁盤。
總之,在配置額外的 CPU 前,必須確定 Web 應用程序是受 CUP 限制,而不是受網絡或磁盤 I/O 限制。
對於受 CPU 限制的應用,最初在每個 CPU 上對一個 WebLogic 實例進行性能測試。如果 CPU 利用率是一致的或者接近 100 %,然後增加 CPU 比重(例如,爲一個 WebLogic 實例配置兩個 CUP ),記住在產品模式下,應該有一些空閒的 CPU 週期存在去執行管理任務。
雖然 Web 應用程序的處理需求變化多端,但 BEA 公司發現 WebLogic 實例與 CPU 最理想的比例是 1 : 2 。
十、監視 WebLogic 域
監視 WebLogic 域的健康狀況和性能的工具是管理控制檯。通過控制檯,你可以觀察到 WebLogic 資源的狀態和統計信息,如服務器, HTTP , JTA 子系統, JNDI, 安全, CORBA 連接池, EJB , JDBC 以及 JMS 。
舉個例子,在 Server ―― >Monitoring ―― >Performance 爲當前服務器實例提供了與等待和運行狀態的請求有關的性能參考。它包括下列信息:
n 隊列中空閒線程數。
n 隊列中等待時間最長的請求。
n 吞吐量,根據已經處理的請求數來衡量的。
n 隊列長度,根據隊列中等待請求數來衡量的。
n JVM 堆還有的內存量。
|