Load Balancing with Enterprise Message Service

Load balancing is typically achieved by combining Substation ES internal dispatching features with Enterprise Message Service load balancing techniques.

Internally, Substation ES has its own dispatching based on the MAXUOW configuration parameter and on the service payload. The MAXUOW parameter specifies the maximum concurrent activities Substation ES can perform at any point. Together with Enterprise Message Service load-balancing servers and connection factories, that is the way load balancing is typically performed. Overhead for some of those operations occurs where the payload for a service originates.

Limitations of EMS-Substation ES Load Balancing

Beware of the following two limitations of the Enterprise Message Service-Substation ES load balancing techniques:

  • Do not specify load balancing in situations with durable subscribers.
    • If a client program that creates a durable subscriber, connects to Server A through a load balanced connection factory, then Server A creates and supports the durable subscription.
    • If the client program exits, restarts, and connects to Server B, then Server B creates and supports a new durable subscription. However, the pending messages on Server A remain there until the client reconnects to Server A.
  • Do not specify load balancing if your application requires strict message ordering. Load balancing distributes the message load among multiple servers. This is a practice that inherently violates strict ordering.

Limit of Resources Consumed by Substation ES

Each Substation ES interface contains a worker parameter that represents the number of concurrent tasks it dispatches to perform activities for its related work. In CICS Interface, the worker parameter is associated with concurrent connections to a CICS region. Specify the appropriate number of workers for the resources available and the workload Substation ES must perform. A value between 10 and 25 is usually adequate.

Note: Substation ES also provides a "limit" value at the Recipe Service level. When set, this limit specifies the maximum number of instances of that service that Substation ES permits in a single ESB interface. With this feature, you can easily control concurrency and cap resource usage when executions are scheduled to go to DB2 or other back-end intensive applications.

Monitoring of Transaction Execution and Queues

In case of a shortage of specified workers or if resources are not available to execute transactions, requests are queued internally and the MAXUOW limit is eventually reached. Internal Substation ES logic slows down in the asynchronous input, causing a backlog and issuing appropriate STRESS level messages. Run the operational command SHOW,UOW to determine if any excessive queue waits have occurred.