[转帖]tuxedo的MMSQ负载均衡的探讨_MQ, Tuxedo及OLTP讨论区_Weblogic技术|Tuxedo技术|中间件技术|Oracle论坛|JAVA论坛|Linux/Unix技术|hadoop论坛_联动北方技术论坛  
网站首页 | 关于我们 | 服务中心 | 经验交流 | 公司荣誉 | 成功案例 | 合作伙伴 | 联系我们 |
联动北方-国内领先的云技术服务提供商
»  游客             当前位置:  论坛首页 »  自由讨论区 »  MQ, Tuxedo及OLTP讨论区 »
总帖数
1
每页帖数
101/1页1
返回列表
0
发起投票  发起投票 发新帖子
查看: 4021 | 回复: 0   主题: [转帖]tuxedo的MMSQ负载均衡的探讨        下一篇 
linjun
注册用户
等级:中校
经验:2221
发帖:176
精华:2
注册:2013-1-6
状态:离线
发送短消息息给linjun 加好友    发送短消息息给linjun 发消息
发表于: IP:您无权察看 2013-1-6 15:53:12 | [全部帖] [楼主帖] 楼主

在使用 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的特点也是有关的。

以上是一些个人分析和测试的结果,算是写出来和大家探讨,也希望大家提出自己的看法并讨论




赞(0)    操作        顶端 
总帖数
1
每页帖数
101/1页1
返回列表
发新帖子
请输入验证码: 点击刷新验证码
您需要登录后才可以回帖 登录 | 注册
技术讨论