在使用TUXEDO的過程中，會遇到一些併發請求量很大的情況，比如某些帳單處理服務或者是在營業下班前的日操作清單服務。這時，一些SERVICE會接收到大量客戶端，甚至長時間的請求，對service，甚至整個系統是嚴峻的考驗。遇到這種情況，單個的server往往難以應付，或者性能不好，我們就想到負載均衡或者使用TUXEDO的MSSQ（Multi Server, Single Queue）。下面筆者根據自己在TUXEDO應用開發和管理配置方面的實踐，結合實際系統壓力測試的結果對相關的問題進行一些探討。
在沒有負載均衡的情況下，是由一個server（可能包含一個或多個service）來處理客戶端對其中service的請求，所有的請求首先放入這個server的隊列裏面，然後server逐個取出處理。在UNIX系統上，TUXEDO較多的使用了隊列，並且也用到了共享內存和信號量，相關的UNIX系統參數會影響到系統的性能，但這個不在本文討論範圍之內，這裏假設已經調到了合適的範圍，具體請查閱TUXEDO關於IPC的文檔。
現以一個帳單處理的server爲例，負載均衡前server的ubb配置爲：
billpay SRVGRP=GROUP1 SRVID=1
在單個server不能滿足性能要求的情況下，就考慮採用TUXEDO的負載均衡方法。
方法一是直接將相關server啓多份，將上面的配置改爲：
billpay SRVGRP=GROUP1 SRVID=1 MIN = 5 MAX = 10
這樣tmboot的時候，就會有MIN = 5個billpay啓動，類似下面的情況：
billpay 00001.00001 GROUP1 1 0 0 ( IDLE )
billpay 00001.00002 GROUP1 2 0 0 ( IDLE )
（依此類推，共5個）
其中第二列是該server的隊列名，"."前面是GRPNO,後面是SRVID，每個server有自己的隊列。相關的另一個參數就是在ubb的*RESOURCES段的LDBAL，表示是否啓動Load Balancing，默認是"N"（不啓動），你可以通過設置成"Y"來啓動。這裏需要注意的是，爲"N"的時候並不表示多個server不能分擔負載。主要的差別是爲"Y"時，TUXEDO在接收到請求時會按照它的負載均衡的算法來找到合適的server來處理，而設置成"N"時，總是由第一個可用的server來處理。通過這種方法可以讓多個server來處理大量併發的請求，就達到了改善性能的目的。
方法二是採用MSSQ（Multi Server, Single Queue），顧名思義，就是有多份server，但是隻有一個隊列（請求隊列）。具體的配置是：
billpay SRVGRP=GROUP1 SRVID=1 MIN = 5 MAX = 10
RQADDR=" billpay" REPLYQ=Y
啓動後的情況如下：
billpay billpay GROUP1 1 0 0 ( IDLE )
billpay billpay GROUP1 2 0 0 ( IDLE )
（依此類推，共5個）
我們發現幾個billpay server都關聯相同的名爲billpay的隊列，這就是所謂的Single Queue。
與直接多server相比，多了兩個參數，RQADDR是這多個server共用的隊列名，是一種邏輯名，可以自己命名，不和別的衝突就可以，REPLYQ是標示是否設置返回隊列，在使用MSSQ的時候是強烈建議設置，因爲這樣可以將請求和返回分開，避免多個server共用隊列時造成混亂。相關的其它參數這裏沒有詳細列出。
到底兩種方式和沒有負載均衡時有什麼不同，後面將提供相關的測試結果。先分析一下兩種方法。方法一有多個隊列可以容納請求，但是這些大量的請求怎樣放入這些隊列必定有一定的策略，而且根據LDBAL的設置會不同，但是這個策略本身的運算也是一種消耗，因爲每個請求都面臨着這個選擇。因爲這種情況下每個隊列是和server對應的，所以隊列的選擇就意味着選擇了相應的那個server，這樣大量的請求就被分流。雖然有選擇的消耗，但是額外的好處也是顯而易見的，那就是有多個queue可用，有效避免了請求併發量很大時隊列的溢出，這種情況在實際的壓力測試中發生過。使用方法二時，放入隊列時不用做選擇，然後每個server的任務就是從隊列取出請求去處理，考慮到多個server併發取隊列，所以用MSSQ時其server的數目不宜太多，官方文檔建議2－12。而且在這種情況下，建議不要設置LDBAL=Y，因爲MSSQ本身就是一種基於single queue的負載均衡的方法，這時再使用系統的策略已經沒有意義。這種方法也有一個問題，如果相對於請求數來說，處理得不夠快，就比第一種方法更容易造成隊列溢出。
因爲我們無法知道TUXEDO一些具體的算法和策略，那就用一些具體的測試來比較吧。筆者在一個和實際生產系統配置相同的UNIX+ORACLE+TUXEDO8.0系統上做了一下試驗，被測服務是一個帳單查詢服務，每次根據一批ID從數據庫查詢出具體的帳單，由於都是實際數據和實際使用的服務，有一定的說明力，但是也不排除一些情況造成的誤差。以下是測試的一些結果，每個server的實際運行份數都是10。
一：客戶端數目爲1，循環調用100次。
1． 方法一，LDBAL = Y or N。結果發現所有的請求都由其中的一個server處理，其它全部空閒。在此基礎上再進行兩次循環調用，結果還是一樣。
2． 用方法二，LDBAL = Y or N。其中兩次測試的情況是：
<1>19，19，2，2，1，18，18，1，1，19
<2>23，8，23，23，23，（其它空閒）
以上數據說明了兩種方式的調度策略是不一樣的，在單客戶端循環的情況下方法二更合適。
二：客戶端數目50，每個循環80次，統計總的執行時間。
1． 用single server。兩次測試的處理時間分別是219s和196s。
2． LDBAL = Y 方法一：三次測試時間爲：63s，79s，69s
3． LDBAL = N 方法一：三次測試時間爲：74s，79s，85s
4． LDBAL = Y 方法二：三次測試時間爲：74s，73s，77s
5． LDBAL = N 方法二：三次測試時間爲：78s，76s，75s
通過以上數據可以看出不管用那種方法，使用負載均衡相比單個server都可以在大量請求併發時得到更好的性能。但是同時也發現後四種情況的總時間差別不大，考慮一些實際的誤差，很難斷定哪種更好。
通過前面的分析，並查閱相關的文檔，建議採用的是兩種方式：多個server，不用MSSQ,設置LDBAL = Y；用MSSQ，設置LDBAL = N。當然，在使用TUXEDO的應用系統中，不能絕對的說哪一種方式更好，只能是根據具體的情況來分析，並通過實際的壓力測試來進行選擇，而且這個和具體server的特點也是有關的。
