優化
WebLogic
服務器性能參數
WebLogic 配置文件（config.xml）包含了大量很直觀的與性能有關的參數，能通過配置環境與應用程序得到很好的優化。基于系統的需要調整這些參數不僅能改善單個點的性能，而且能提高整個應用程序性能的可衡量性。
試著采用下列WebLogic配置方法，或許能使你的系統達到最佳狀態：
一 修改運行隊列線程數的值。在WebLogic 中隊列元素的線程數等于同時占用運行隊列的應用程序的數目。當任務加入一個WebLogic 實例，它就被放到執行隊列中，然后分配給任務一個線程來運行。線程消耗資源，因此要小心處理這個屬性——增加不需要的值，會降低性能。
二，如果可能，使用自帶的性能包（NativeIOEnabled=true）。
三，使用特定的應用程序執行隊列。
四，使用JDBC連接池時，修改下列屬性：
n???????? 驅動名稱：使用小的驅動或者jDriver。
n???????? 初始容量：設為與最大容量相同的值。
n???????? 最大容量：其值至少應與線程數相同。
五，把連接池的大小設為與執行隊列的線程數相同。
六，設置緩沖。
七，為Servlet和JSP使用多個執行隊列。
八，改變JSP默認的Java編譯器，javac 比jikes或sj要慢。
?
優化
WebLogic
提要：
n
????????
為
WebLogic
啟動設置
Java
參數。
n
????????
設置與性能有關的配置參數。
n
????????
調整開發與產品模式默認值。
n
????????
使用
WebLogic
“自有的
IO
”性能包。
n
????????
優化默認執行隊列線程。
n
????????
優化連接緩存。
n
????????
如何提高
JDBC
連接池的性能。
n
????????
設置
Java
編譯器。
n
????????
使用
WebLogic
集群提高性能。
n
????????
監視
WebLogic
域。
一、為
WebLogic
啟動設置
Java
參數
只要啟動
WebLogic
，就必須指定
Java
參數，簡單來說，通過
WebLogic.Server
域的命令行就可以完成，不過，由于這樣啟動的過程冗長并且易于出錯，
BEA
公司推薦你把這個命令寫進腳本里。為了簡化這個過程，你可以修改樣例腳本里的默認值，樣例腳本是提供
WebLogic
啟動服務器的。
如果你用配置向導創建你的域，
WebLogic
啟動腳本（
startWebLogic.cmd
）放在
domain-name
目錄里。默認情況下，這個目錄是
BEA_HOME\user_projects\domain\domain-name
，
BEA_HOME
表示安裝路徑，
domain-name
是在配置模板中設置的域名稱。
你需要在這個腳本中修改一些默認的
Java
參數值，使之適合你的應用環境和程序。在這個文件中主要的性能參數是
JAVA_HOME
和
Java
堆的大小。
n
????????
設
JAVA_HOME
的值為
JDK
所在的位置，如：
set JAVA_HOME=C:\bea\jdk141_03
n
????????
為得到高性能的吞吐量，把
Java
堆的最小值與最大值設為相等。如：
"%JAVA_HOME%\bin\java" -hotspot -Xms512m -Xmx512m -classpath %CLASSPATH% -
二、設置與性能有關的配置參數
在一個
WebLogic
域中，配置文件（
config.xml
）位于與管理服務器通信的機器里，提供
WebLogic MBean
的長期存儲。管理服務器作為連接的中心點，為服務實例與系統管理工具提供服務。域也可以包括其他的
WebLogic
實例，稱之為從服務，主要為應用程序提供服務。
當啟動管理服務器是，首先讀域配置文件，然后跳過建立在配置文件中管理
MBean
默認的屬性值，每一次用系統管理工具（不管是命令行界面還是管理控制臺）改變一個屬性值，它都會被存到相應的管理
MBean
，并且寫進配置文件。
下表列出了
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
(聲明高速緩沖大小)
|
?
|
?
三、調整開發模式與產品模式默認值
你可以指定域為開發環境或為產品環境。
WebLogic
會根據你指定的環境類型使用不同的默認值提供不同的服務。
下表列出了兩種模式下的默認值
|
優化參數
|
開發模式
|
產品模式
|
|
Execute Queue:
ThreadCount
|
15 threads
|
25 threads
|
|
JDBC Connection Pool:
MaxCapacity
|
15 connections
|
25 connections
|
3
．
1
更改運行時模式
在創建了一個域后，按下列步驟可以更改域里所有服務的的運行時模式：
?
1
．為更改運行在一個
WebLogic
主機上的所有域的運行時模式，用文本編輯器打開
WL_HOME\common\bin\commEnv.cmd(Windows)
或者
WL_HOME\common\bin\commEnv.sh (UNIX)
，
WL_HOME
是安裝
WebLogic
的路徑。
為指定的域更改運行時模式，就用文本編輯器打開
domain-name
\StartWebLogic.cmd (Windows) or domain-name\StartWebLogic.sh (UNIX)
，
domain-name
為創建的域的目錄。
2
．在這個腳本中，更改
PRODUCTION_MODE
的值，如果你要服務器運行在產品模式，指定其值為
TRUE
。
3
．重啟所有的服務器。
3
．
2
兩種模式的不同
下表列出了開發模式與產品模式幾種關鍵項的區別：
|
功用名稱
|
開發模式
|
產品模式
|
|
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
。
|
四、使用WebLogic“自有的IO”性能包
當你使用自有的性能包，測試基準就表明了主要性能的提高。性能包采用最優化的平臺及多線程的
Socket
去提高服務器的性能。例如，本地
Socket
讀的多線程有自己的執行隊列而不需要借用默認的執行隊列線程，這樣可以讓默認執行線程很從容去處理應用程序。
不過，如果你一定要用純
Java socket
讀在主機上運行，你仍然可以通過配置每個服務器實例和客戶機中適當的
socket
讀的線程數量，來提高
socket
通信的性能。
設置性能包的操作方法：
默認情況下，裝載在
config.xml
中的是自有的性能包。為了驗證這個設置，在配置文件中檢查
NativeIOEnabled
屬性是否設為“
true
”（
NativeIOEnabled=true
）。
你也可以通過管理控制臺來驗證，步驟如下：
1
，
???
啟動管理服務器。
2
，
???
訪問管理控制臺。
3
，
???
展開左邊面板的
Servers
節點，顯示域服務。
4
，
???
點擊你要配置的服務實例。
5
，
???
選擇
Configuration
－
>Tuning tab
。
6
，
???
如果
Enable Native IO
復選框沒有被選擇，選中即可。
7
，
???
點擊
Apply
。
8
，
???
重啟服務器。
?
?
五、優化默認執行隊列線程
默認情況下，一個新的
WebLogic
實例配置了一個開發模式執行隊列，
weblogic.kernel.default,
它包含
15
個線程。另外，
WebLogic
提供了
2
個預配置隊列：
n?????? weblogic.admin.HTTP——只在管理服務器上才有，這個隊列供與管理控制臺的通信用，你不能再配置它。
n?????? weblogic.admin.RMI——管理服務器和被管理服務器上都有這個隊列，它是供管理的交通之用，也不能再配置它。
如果你不配置額外的執行隊列，并且指定應用給這些隊列，
web
應用程序和
RMI
對象就使用默認的隊列
weblogic.kernel.default
。
注意；如果自帶的執行包沒有在你的平臺上使用，你可能需要調整默認的執行隊列線程數和擔任
socket
讀的線程的百分比，去實現最佳性能。
5
．
1
你應該更改默認的線程數嗎
?
增加更多的線程到默認的執行隊列并不意味著你能處理更多的工作。即使增加更多的線程，仍然被處理器的能力限制。因為線程消耗內存，所以增加線程數屬性的值不必要的降低了性能。一個高的執行線程數導致更多的內存被占用并且增加了上下文轉換程序，它也會降低性能。
線程數屬性的值與應用程序處理的工作的類型關系密切。例如，如果你的客戶應用程序比較小，通過遠程調用處理的工作較多，這樣，客戶端會花費更多的時間連接，因此，與能完成大量客戶端任務的客戶應用程序相比，會需要更多的線程數。
如果你的工作不需要使用超過15個線程（開發模式默認）或者25個線程（產品模式默認），就不要改變這個屬性的值。通常，如果你的應用程序訪問數據庫花很長時間才返回結果，與訪問數據庫很短時間就返回的應用程序比較，你會需要更多的執行線程。從后者來看，用少點的線程數可能提高性能。
5
．
2
需要修改默認線程數的情形
為了給執行隊列決定一個理想的線程數，當隊列中所有應用程序都運行在最大負荷的情況下，監視隊列的吞吐量。增加線程數，重復負載測試，直到達到最佳的吞吐量。（在某些情況下，增加線程數將產生足夠多的上下文轉換程序，使得隊列中的吞吐量開始減少。）
注意：
WebLogic
管理控制臺顯示的是所有服務器執行隊列累積的吞吐量。為了得到這個值，后面將會介紹。
下表列出了在WebLogic 域中調整的線程及與CPU數量相關的情形，這些情況也假定WebLogic運行在最大負荷下，并且使用默認的執行隊列滿足所有的線程的請求。如果你配置了額外的執行隊列并指派了應用程序到具體的隊列，就需要依據一個個連接池得到結果。
|
如果…
|
結果
|
應該：
|
|
線程數<CPU的數量
|
線程數太少，如果：
CPU
正等著工作，但有工作被完成。
CPU
利用率不能達到100％。
|
增加線程數。
|
|
線程數＝CPU的數量
|
理論上理想，但是CPU仍然低利用。
|
增加線程數。
|
|
線程數（適當的）>CPU的數量
|
實際中理想，有個適當的上下文轉換程序數量和高的CPU利用率。
|
調整適當的線程數并且比較性能結果。
|
|
線程數（較大的）>CPU的數量
|
過多的上下文轉換程序，能導致重大的性能降級。
當你降低線程數時，性能可以增強。
|
減少線程數，使它等于CPU的數量，然后僅僅增加已經得出的“堵塞”線程的數量。
例如，如果你有4個處理器，它們都同時運行，并出現堵塞線程，于是，你想要的執行線程就是4＋堵塞線程的數
|
5
．
3
修改默認線程數的步驟
用管理控制臺修改默認執行隊列線程數如下：
1．??? 如果管理服務器沒有運行，先啟動。
2．??? 訪問管理控制臺。
3．??? 展開左邊面板的Servers 節點，顯示域服務。
4．??? 右擊服務名稱，在彈出菜單中選擇View Execute Queues ，就會在右邊面板顯示有執行隊列的表用來修改。
注意：你只能修改默認的執行隊列或者用戶定義的執行隊列。
5．??? 在Name列，直接點擊默認執行隊列名稱，顯示配置標簽用來修改執行隊列數。
6．??? 填下適當的線程數。
7．??? 點擊Apply，保存剛才的修改。
8．??? 重啟服務器，使新的執行隊列設置生效。
?
5
．
4
指派應用程序到執行隊列
雖然可以配置默認的執行隊列，為所有的
WebLogic
應用程序提供最佳的線程數，但是為關鍵的應用程序配置多個執行隊列可以提供更多的管理控制。通過使用多執行隊列，你可以保證應用程序有權占用固定的線程數，而不管
WebLogic
服務器有多大的負荷。
5
．
5
創建執行隊列
一個執行隊列代表執行線程的命名集，線程指向一個或多個
Servlet
、
JSP
、
EJB
、
RMI
對象。執行隊列在
config.xml
文件中描述，作為服務器元素的一部分。如，在
config.xml
文件中描述一個有
4
個線程的隊列，命名為
CriticalAppQueue
，如下：
...
<Server
Name="examplesServer"
ListenPort="7001"
NativeIOEnabled="true"/>
<ExecuteQueue Name="default"?
ThreadCount="15"/>
<ExecuteQueue Name="CriticalAppQueue" ?
ThreadCount="4"/>
?...
</Server>
另一種創建隊列的方法是通過管理控制臺，配置步驟如下：
1
．
???
啟動管理服務器，訪問控制臺。
2
．
???
展開左邊面板中
Servers
節點，顯示域中要配置的服務。
3
．
???
右擊你要增加隊列的服務實例，從彈出菜單中選擇
View Execute Queues
。
4
．
???
在隊列配置標簽中，點擊配置新執行隊列鏈接。
5
．
???
在隊列配置標簽中，更改下列屬性或接受系統的默認值：
n
????????
線程名稱（
Name
）：你可以輸入線程名稱，如
CriticalAppQueue
。
n
????????
隊列長度
(Queue Length)
：通常保留默認值
65536
，隊列長度表明了同時發來請求的最大數，
65536
個請求是個很大的數，即使達到這個最大數，也是很少見的。
如果達到最大隊列長度，
WebLogic
會自動成倍增長隊列大小，以處理額外的工作。
注意：超過
65536
個請求預示隊列中的線程有問題，不僅僅只是隊列本身的長度問題，實踐表明在隊列中有堵塞線程或線程數不足的情況存在。
n
????????
隊列長限制百分比（
Queue Length Threshold Percent
）：達到隊列長度百分比（
1
－
99
）時，就構成了溢出條件的產生。實際隊列大小在限制的百分比之下時才被認為是正常的；在限制百分比之上就會產生溢出。當出現溢出，
WebLogic
日志就會產生一個錯誤消息，并且按線程數增量（
Threads Increase
）屬性的值增加線程數，以幫助減少負載量。
默認的隊列長限制百分比為
90
％。一般情況下，應保留
90
％或其左右，以應對一些潛在的情況，使得有額外的線程可以去處理一些請求中的異常。記住，隊列長度限制百分比不是一定作為自動優化參數――因為正常運作情況下，這個限度從不會被觸發。
n
????????
線程數（
Tread Count
）：指派到這個隊列的線程數。如果你不需要使用超過
15
個線程（默認），就不必更改這個屬性值。
?
n
????????
線程數增量（
Threads Increase
）：是指
WebLogic
探測到有溢出時，增加到執行隊列的線程數。當你指定為
0
（默認），出現溢出時，
WebLogic
會把運行良好狀態改為“警告”，而且也不會指派額外的線程去減少負荷量。
?
注意：如果
WebLogic
實例的線程數響應了溢出，那么這些額外的線程就會滯留在執行隊列，直到服務器重啟。監視錯誤日志，以判斷溢出產生的原因，以便根據需要重配置線程數，防止以后類似情況產生。不要同時使用線程數增量和隊列長限制百分比作為自動優化的手段。如此做通常結果會產生比正常需要還多的線程被指派到執行隊列，這樣上下文轉化程序的增多會使服務器遭受很差的性能。
?
n
????????
最大線程數：是指執行隊列中能運行的，這個值保護
WebLogic
為了響應頻繁溢出，創建過多的線程數。默認情況下，最大線程數為
400
。
n
????????
線程優先級：線程優先級與此隊列相關。默認值為
5
。
?
6
．
???
點擊
Create
，創建隊列。
7
．
???
重啟服務器。
5
．
6
指派
Servlet
和
JSP
到執行隊列
你可以把
servlet
或
JSP
分配到指定的配置執行隊列，只需在初始參數中標識執行隊列的名稱。初始參數出現在
Servert
或
JSP
的部署描述文件
web.xml
中的
init-param
元素里。為了分配一個隊列，可以把隊列名作為
wl-dispatch-policy
參數的值。如：
<servlet>
???<servlet-name>MainServlet</servlet-name>
???<jsp-file>/myapplication/critical.jsp</jsp-file>
???<init-param>
??????<param-name>wl-dispatch-policy</param-name>
??????<param-value>CriticalAppQueue</param-value>
???</init-param>
</servlet>
5
．
7
指派
EJB
和
RMI
對象到執行隊列
為了把
EJB
分配到指定的隊列，可以使用
weblogic-ejb-jar.xml
文件中
dispatch-policy
元素。
然而你也可以通過使用
appc
編譯器
－
dispatchPolicy
選項來設置派遣策略，
BEA
強烈推薦使用部署描述元素。因為用這種方式，如果
EJB
重編譯，在部署用例期間，這個設置不會被丟失。
為了把
RMI
對象分配到指定的隊列，可以使用
rmic
編譯器的－
dispatchPolicy
選項，如：
java weblogic.rmic -dispatchPolicy CriticalAppQueue ...
?
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
堆還有的內存量。
jwebee
我的個人網站
posted on 2007-04-19 13:32
周行 閱讀(3452)
評論(2) 編輯 收藏 所屬分類:
IT技術