問題背景：如何對Weblogic JMS叢集進行調優。

調優參考指標：

對於Weblogic JMS叢集的效能調優，在如下這篇文章中有一些總結：
1. 增加-Dweblogic.JMSThreadPoolSize=n(至少為5),以提高處理JMS的執行緒數,在
jRockit上增加-XXenablefatspin以減少加鎖衝突;
2. 採用檔案儲存策略,將同步寫策略設定為Direct-Write,同時在windows平臺上啟用磁碟寫入快取;
3. 使用分散式目的地時,啟用連線工廠Load Balancing Enabled ,Server Affinity Enabled;
4. 為減少伺服器不必要的JMS請求路由,如果多個目的地之間存在事務,則部署在同一JMS伺服器上,儘量將連線工廠部署到JMS伺服器所在的WebLogic例項上,叢集環境下，則最好將連線工廠部署到叢集中的所有伺服器上,而叢集中每個JMS伺服器和目的地成員儘量使用類似的設定；
5. 啟用訊息分頁儲存功能,以釋放記憶體,可以為JMS伺服器和目的地設定, 啟用Messages Paging Enabled和Bytes Paging Enabled,同時使用限額防止伺服器耗盡接收訊息的所有可用記憶體空間;
6. 在執行WebLogic Server程序之外的生產者務必使用流控制, 並增大Send Timeout;
7. 將JMS Server Expiration Scan Interval設很大的值，能禁止主動掃描過期訊息;
8. 使用FIFO或者LIFO方式處理目的地訊息;
9. MDB的max-beans-in-free-pool不應大於最大MDB執行緒數(預設執行緒數/2+1)。

對於web應用伺服器和後臺處理伺服器：

監控伺服器資源，發現叢集平臺伺服器負載並不高，而web應用伺服器負載同樣也不高，伺服器效能並沒達到瓶頸。進入weblogic控制檯，檢視執行緒池，發現在壓1000併發的時候，請求積壓佇列明顯較多，而執行緒數只有50左右。說明一下，weblogic產品模式下，預設初始執行緒數為25，開發模式下好像是15，weblogic11g採用的是自調整執行緒池，看名字就可以猜出，他會根據應用情況自動增加減少執行緒數，而實際情況下，在壓力增大的情況下，weblogic也確實增加了執行緒數，但是增加的執行緒數不足以應付該需求，於是自然而然地想到了增加執行緒數。

1.增加前臺Weblogic伺服器和後端Weblogic伺服器記憶體和執行緒數。一般原則為一個cpu對應50個執行緒。

weblogic11g已經不支援在控制檯修改執行緒數，只能通過配置檔案，網上有朋友說可以通過增加weblogic啟動引數來配置執行緒數: 
-Dweblogic.threadpool.MinPoolSize=100 
-Dweblogic.threadpool.MaxPoolSize=500 
該方法經試驗，並不能生效，還好還一種方法，修改域下面conf裡面的config.xml檔案： 
<server> 
<name>AdminServer</name> 
<self-tuning-thread-pool-size-min>400</self-tuning-thread-pool-size-min> 
<self-tuning-thread-pool-size-max>400</self-tuning-thread-pool-size-max> 
<listen-address/> 
</server> 
在這裡把執行緒數最大值最小值都設成了400，400這個數值不是亂設的，WebLogic可以近乎線性地提高執行緒數。執行緒數越多，花費線上程切換的時間也就越多；執行緒數越小，CPU可能無法得到充分的利用。為獲取一個理想的執行緒數，需要經過反覆的測試。一般來說一個CPU最好小於50個執行緒數

2.在後臺Weblogic伺服器工程中，對JMS訊息的處理啟動多執行緒。

3.JDBC連線池限制

如果網路和資料量都沒有問題，則會考慮交易到資料庫的連線數是否有限制，和資料庫操作的那些交易的SQL請求根本沒有到達資料庫伺服器。我們可以通過中介軟體的控制檯檢視JDBC的最大容量（此連線緩衝池可容納的最大物理連線數）

4.1資料庫JDBC連線池限制，設定的本來就小，weblogic預設最大容量為50。

4.2如果一臺應用伺服器上是多路進行部署的話，檢視各路JDBC連線是否均衡

調優原則：

1、出現效能瓶頸時，先找出現瓶頸的地方，是應用伺服器還是資料庫伺服器 
2、判斷是否需要修改weblogic執行緒數以及資料庫連線池的值 
3、多次測試，得出一組合適的weblogic執行緒數的值以及資料庫連線數的值