優化WebLogic

 

優化WebLogic

優化 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 堆還有的內存量。