Load balancing test for WebLogic connecting Oracle RAC ____oracle

To perform stress testing, the middleware uses WebLogic 816, the database version is 11.1.0.6 RAC, and the stress test tool is LoadRunner 8.0. Test the load on individual nodes of a single instance and RAC environment.

A multiple pool is configured on the WebLogic, and the concurrent equilibrium is divided into two nodes by using the load balancing strategy provided by WebLogic.

But the test found that once running for a while, all the pressure was loaded onto one node, and the other node had no pressure on the opportunity.

The results of the query from the database are as follows:

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 concurrency is set to 150, while LoadRunner concurrency is 600 for each instance of Oracle.

As you can see, basically the pressure is fully concentrated on instance 2. Instance 1 is idle, and if the stress test runs long enough, the active connection on instance 1 can reach around 20 or 30 in a short time, but it will be released all at once.

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

Tested many times, the results are very similar, the pressure is almost completely concentrated on a node. But not every time the pressure is on Node 2, it is likely that after the WebLogic service reboot, the next test starts, all the pressure is focused on node 1. This indicates that the problem should not be caused by the unbalanced hardware handling of the two nodes.

This test is a long-running query, and for quick INSERT statements, you can see that there are very few active sessions on two nodes. This is not a problem because transaction processing is short-lived and it is not possible to make WebLogic concurrency run full in a short time.

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

For a long time query, WEBLOGIC's load-balancing strategy appears to be problematic, resulting in two node pressure skew. Beginning to think that it might be because the WebLogic version was too low to cause the problem, the WebLogic was upgraded to the latest version 10.3, but the test results were still the same.

Since the previous test used a WebLogic load-balancing strategy, the hing-availability strategy was found to be more consistent with its own name, but there were some problems. This strategy overrides the first connection pool in the pool and does not use the second connection pool if the first connection pool can be connected mulit. WEBLOGIC does not attempt to use a second connection pool, even if there are too many concurrent users, causing many connection timeout errors. When instance 1 is closed in the background, the connection pool 1 connection fails, and WebLogic starts using the second connection pool. Once instance 1 is started, WEBLOGIC detects that connection pool 1 is available, and immediately all connections are transferred from connection Pool 2 to connection pool 1, before instance 1 is closed. Based on the above situation, the sense WebLogic only realizes the priority setting of the connection pool, rather than the high-availability in the real sense.

Pull far, the following continue to say WebLogic load-balancing. Because the upgrade to the latest version can not solve the problem, had to search the network, the results found a lot of similar cases. However, no solution was found.

However, an article in Metalink mentions that you can use the configuration in Oracle Tnsnames.ora directly after the url= "jdbc:oracle:thin@" in WebLogic.

For example, configure 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)) "

This approach actually bypasses the WebLogic load-balancing mechanism and directly uses the RAC load-balancing strategy, resulting in the following test results:

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's load balancing implementation is still relatively good, basically two nodes of the load difference is very small. The same applies for situations where the load is small:

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

The test results found that it would be better to use Oracle's load-balancing strategy rather than using the load-balancing policy provided by WebLogic in order to achieve an ideal load balance in all situations.