WEBLOGIC连接Oracle RAC 的负载均衡测试

要进行压力测试，中间件使用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 策略。