其中第二列是该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 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。其中两次测试的情况是：

以上数据说明了两种方式的调度策略是不一样的，在单客户端循环的情况下方法二更合适。

二：客户端数目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的特点也是有关的。