Workload balancing

Workload balancing is the routing of transactions or programs among a group of target regions according to the availability and activity levels of those target regions. Workload balancing can be used in addition to, or in place of, workload separation. For example, CICSPlex® SM can balance the workload among the SALESGRP target regions by selecting, as each transaction is initiated, the target region that is likely to deliver the best performance.

Which target region processes the work is determined wholly by CICSPlex SM using one of two algorithms. These are the queue algorithm and the goal algorithm.

Workload balancing is statistical in nature. Selection of the appropriate target region is based completely on the target region’s ability to achieve the expected response time when utilizing the goal algorithm, or balancing the load across a set of target regions when using queue. If all the target regions in a set are equally capable of handling the work within the constraints of link type, abend probability, health, normalized load and response time (for goal), then a target region is randomly selected from the resulting set. Therefore, in systems that are lightly loaded, there is no predetermined order in which work is allocated to equally capable target regions, since the target regions are by definition equally capable of achieving the desired effect. This is in contrast to some balancing algorithms that use a "round robin" technique, whereby work is allocated to the given set of target regions simply by allocating the next instance to the next target region in the ring.

When selecting a target region, both the queue algorithm and the goal algorithm take into account the way in which a target region is connected to its requesting region. That is, a target region connected to its requesting region via MRO/XCF is preferred to a VTAM®-connected target region, when all other considerations are equal. For workload balancing of enterprise-bean related requests, only MRO connections between routing regions and target regions are supported.

Workload balancing of enterprise beans can be achieved using the queue and goal algorithms. The inbound IIOP work request is received by a routing region (listener) and is matched to a bean name, an operation and a CorbaServer using a request model definition. The routing region routes the transaction identified in the request model to a target region. The transaction runs in the CorbaServer corresponding to the installed request model instance.

The queue algorithm

The queue algorithm causes CICSPlex SM to select the target region that:

This algorithm maximizes work throughput and standardizes response times across the CICSplex. The queue algorithm is very robust: it can accommodate differences in processor power; different maximum task values in the target regions; asymmetric target region configurations; and an unpredictable workload.

The goal algorithm

The goal algorithm causes CICSPlex SM to select the target region that:

MVS/ESA 5.1 (or later) is a prerequisite of the goal algorithm. Also, routing regions in a CICSplex using the goal algorithm must be CICS TS regions.

The goal algorithm works best in environments where, if the CICSplex crosses multiple MVS™ images:

Start of change

Cross CEC routing

CPSM routing regions use task load percentages ((active tasks/maxtask) *100) in available target regions as part of the determination for which target region to route to. The percentage value, which is set by the WLMLOADTHRSH EYUPARM, must be met by all target regions on the same CEC as the routing region before the routing region routes to target regions on other CECs, if all other health factors (for example, short-on-storage) for the target regions are similar. Once all target regions on other CECs meet this value, the routing region resumes routing to the target regions on the local CEC again. When a local target's task load drops below this value the routing region resumes routing to that target region regardless of the task load in target regions on remote CECs.

For example, if the default value of 65 is used, then all target regions on the CEC where this routing region resides must have a task load of 65% or higher before the routing region routes to target regions on other CECs, if all other health factors (for example, short-on-storage) for the routing regions are similar. As soon as target regions on other CECs achieve a task load of 65% or higher, the outing region resumes routing to the target regions on the local CEC again. When a local target region's task load drops below 65%, the routing region resumes routing to that target region regardless of the task load in target regions on remote CECs.

Specifying this value lower than the default probably decreases the delay in routing to target regions on remote CECs. Take care not to set this value so low that the threshold is met by long-running tasks in the target regions.

Specifying this value higher than the default most likely increases the delay in routing to target regions on remote CECs.

Note that the effectiveness of this parameter is increased as the characteristics (for example, maxtask value or number of long running tasks) of the target regions become similar.

End of change [[ Contents Previous Page | Next Page Index ]]