WEBLOGIC連線OracleRAC的負載均衡測試(轉載)

　要進行壓力測試，中介軟體使用WEBLOGIC 816，資料庫版本為11.1.0.6 RAC，壓力測試工具為LOADRUNNER 8.0。測試單例項與RAC環境各個節點的負載情況。
　　在WEBLOGIC上配置了一個多池，利用WEBLOGIC提供的負載均衡策略，將併發均衡的分別到兩個節點上。
　　但是測試發現，一旦執行了一段時間，所有的壓力都會載入到一個節點上，而另一個節點上機會沒有任何的壓力。
　　透過資料庫中查詢到的結果如下：
　　SQL> SELECT INST_ID, STATUS, COUNT(*)
　　2 FROM GV$SESSION
　　3 WHERE USERNAME = ’NDMAIN’
　　4 GROUP BY INST_ID, STATUS;
　　INST_ID STATUS COUNT(*)
　　---------- -------- ----------
　　1 INACTIVE 6
　　1 ACTIVE 1
　　2 ACTIVE 147
　　2 INACTIVE 3
　　WEBLOGIC的併發設定為150，而LOADRUNNER併發為200，Oracle每個例項的SESSION為600。
　　可以看到，基本上壓力完全集中在例項2上。例項1上處於空閒狀態，如果壓力測試執行時間足夠長，可能在短時間內例項1上的ACTIVE連線能達到二、三十左右，但是很快又全部釋放。
　　SQL> SELECT INST_ID, STATUS, COUNT(*)
　　2 FROM GV$SESSION
　　3 WHERE USERNAME = ’NDMAIN’
　　4 GROUP BY INST_ID, STATUS;
　　INST_ID STATUS COUNT(*)
　　---------- -------- ----------
　　1 ACTIVE 20
　　1 INACTIVE 54
　　2 ACTIVE 121
　　2 INACTIVE 28
　　測試了多次，結果都很類似，壓力幾乎完全集中到一個節點上。不過不見得每次壓力都是在節點2上，很有可能在WEBLOGIC服務重啟之後，下次測試開始，所有的壓力都集中到節點1上。這說明問題應該不是兩個節點的硬體處理不平衡造成的。
　　這個測試的是長時間執行的查詢，而對於快速相應的INSERT語句，可以看到兩個節點上都有很少的ACTIVE的會話。這時因為事務處理很短暫，不可能在短時間內使得WEBLOGIC的併發跑滿，因此這種情況沒有問題

SQL> SELECT INST_ID, STATUS, COUNT(*)
　　2 FROM GV$SESSION
　　3 WHERE USERNAME = ’NDMAIN’
　　4 GROUP BY INST_ID, STATUS;
　　INST_ID STATUS COUNT(*)
　　---------- -------- ----------
　　1 INACTIVE 50
　　1 ACTIVE 1
　　2 ACTIVE 1
　　2 INACTIVE 98
　　對於長時間查詢的情況，WEBLOGIC的LOAD-BALANCING策略似乎存在問題，導致兩個節點壓力出現傾斜。開始認為可能是由於WEBLOGIC的版本太低導致了問題的產生，於是將WEBLOGIC升級到了最新的版本10.3，可是測試結果依舊。
　　由於前面測試使用的都是WEBLOGIC的LOAD-BALANCING策略進行的，嘗試了一下HING-AVAILABILITY策略，發現這個策略倒是和它本身的名稱更相符一些，但是也存在一定的問題。這個策略會優先MULIT POOL中的第一個連線池，如果第一個連線池可以連線，就不使用第二個連線池。即使併發使用者太多，導致很多連線超時的錯誤，WEBLOGIC也不會去嘗試使用第二個連線池。當後臺關閉例項1，導致連線池1的連線失敗，這時WEBLOGIC開始使用第二個連線池。一旦例項1啟動，WEBLOGIC檢測到連線池1可用，馬上所有的連線都會從連線池2上轉移到連線池1，恢復到例項1關閉之前的情況。基於上面的情況，感覺WEBLOGIC只是實現了連線池的優先順序設定，而不是真正意義上的HIGH-AVAILABILITY。
　　扯遠了，下面繼續說WEBLOGIC的LOAD-BALANCING。由於升級到最新版本都無法解決這個問題，只好在網路上搜尋，結果發現不少相似的案例。不過沒有發現解決方案。
　　不過在metalink裡面的一篇文章提到可以在WEBLOGIC裡面的URL=”jdbc:oracle:thin@”後面直接使用Oracle的tnsnames.ora中的配置。
　　比如這裡配置URL=”jdbc:oracle:thin@ (DESCRIPTION= (ADDRESS= (PROTOCOL=TCP) (HOST=172.0.2.58) (PORT=1521)) (ADDRESS=(PROTOCOL=TCP) (HOST=172.0.2.59) (PORT=1521)) (LOAD_BALANCE=yes)(CONNECT_DATA=(SERVER=DEDICATED) (SERVICE_NAME=rac11g.us.oracle.com))”
　　這種方式實際上繞過了WEBLOGIC的負載均衡機制，而直接使用了RAC的負載均衡策略，結果測試結果如下：
　　SQL> SELECT INST_ID, STATUS, COUNT(*)
　　2 FROM GV$SESSION
　　3 WHERE USERNAME = ’NDMAIN’
　　4 GROUP BY INST_ID, STATUS;
　　INST_ID STATUS COUNT(*)
　　---------- -------- ----------
　　1 ACTIVE 75
　　1 INACTIVE 6
　　2 ACTIVE 75
　　2 INACTIVE 5
　　Oracle的負載均衡的實現還是比較好的，基本上兩個節點的負載差別很小。對於負載較小的情況也同樣適用：
　　SQL> SELECT INST_ID, STATUS, COUNT(*)
　　2 FROM GV$SESSION
　　3 WHERE USERNAME = ’NDMAIN’
　　4 GROUP BY INST_ID, STATUS;
　　INST_ID STATUS COUNT(*)
　　---------- -------- ----------
　　1 INACTIVE 8
　　1 ACTIVE 1
　　2 ACTIVE 2
　　2 INACTIVE 7
　　測試結果發現，要想在任何情況下都獲得比較理想的負載均衡，最好使用Oracle的負載均衡策略，而不要使用WEBLOGIC的多池提供的LOAD-BALANCING策略。