Tuning Messaging System Performance

This chapter discusses how to:

• Throttle dispatched messages through the messaging system.

• Configure integration gateways for load balancing.

• Use multi-threading to send groups of messages in parallel.

• Implement master-slave dispatchers.

Understanding Tuning Messaging System Performance

This chapter discusses actions you can take to tune messaging system performance.

In addition, you can view messaging system performance statistics using Integration Broker Monitor.

See Also

Viewing Messaging System Performance Statistics

Throttling Dispatched Messages Through the Messaging System

You can throttle the number of dispatched messages from a given dispatcher to its associated handler(s).

Throttling the messages that pass through the messaging system enables you to avoid Tuxedo queue saturation due to redundant Tuxedo calls, which result in degraded performance.

You can throttle messages on any of the three pub/sub dispatchers:

• PSBRKDSP

• PSPUBDSP

• PSSUBDSP

To set up dispatcher throttling, you must set the following parameters located in PSADMIN:

• Tuxedo Queue Status Check Count

• Dispatcher List Multiplier

• Dispatcher Channel Max Queue Size

Information for setting these parameters is described earlier in this PeopleBook.

See Specifying Dispatcher Parameters.

Using Multi-Threading to Send Groups of Messages in Parallel

This section provides an overview of multi-threading and discusses how to:

• Specify the number of available threads.

• Implement multi-threading.

Understanding Multi-Threading

You can gather a group of synchronous requests and send them in parallel, thereby eliminating the need to wait for a response for one synchronous message to be returned, before you send the next synchronous message. You can also use multi-threading to send a configurable number of publications (asynchronous messages) in parallel.

Multi-threading enables you to pool request messages into an array and make a threaded call.

When working with synchronous messages, responses are returned in an array, and are pooled in the same order in which you send them.

Multi-threading supports sender-specified routing, thereby enabling you to pass in an array of nodes on the SyncRequest call.

Specifying the Number of Available Threads

The number of threads available determines the number of message you can send in parallel. For example, if there are 10 threads available, you can send 10 messages in parallel.

To specify the number of threads available for multi-threading set the following parameter in PSADMIN:

Thread Pool Size

Setting the Thread Pool Size for Synchronous Messaging

For synchronous messaging, set the Thread Pool Size parameter in the General Settings for Integration Broker section in PSADMIN.

For synchronous messaging, The default value is 5. The minimum value is 1 and the maximum value is 20.

Setting the Thread Pool Size for Asynchronous Messaging

For asynchronous messaging, set this parameter in the Settings for Publication Contract Handler section in PSADMIN.

For synchronous messaging, The default value is 1. The minimum value is 1 and the maximum value is 20.

Implementing Multi-Threading

This section provides the syntax for multi-threading and provides a synchronous multi-threading code example.

Syntax

The syntax for implementing multi-threading is:

Array of messages = %InBroker.SyncRequest(Array of messages, array of sender-specified routing);

Synchronous Multi-Threading Example

The following example shows code for synchronous multi-threading

Local Rowset &FLIGHTPLAN, &FLIGHTPLAN_RETURN;
Local Message &MSG;

Local array of Message &messages;
Local array of Message &return_mesages;

&messages = CreateArrayRept(&MSG, 0);
&return_mesages = CreateArrayRept(&MSG, 0);

&FLIGHT_PROFILE = GetLevel0();
&messages [1] = CreateMessage(Message.QE_FLIGHTPLAN_SYNC);
// populate the rowset
&messages [1].CopyRowset(&FLIGHT_PROFILE);

&messages [2] = CreateMessage(Message.QE_FLIGHTPLAN_SYNC);
// populate the rowset
&messages [2].CopyRowsetDelta(&FLIGHT_PROFILE);

&return_mesages = %IntBroker.SyncRequest(&messages);

// process the return rowset
&FLIGHTPLAN_RETURN = &return_mesages [1].GetRowset();
&temp = &return_mesages [1].GenXMLString();

// process the return rowset
&FLIGHTPLAN_RETURN = &return_mesages [2].GetRowset();
&temp = &return_mesages [2].GenXMLString();

Implementing Master-Slave Dispatchers

Configuring a domain as a slave domain enables you to increase message processing throughput. This section provides an overview of master-slave dispatcher processing and describes how to configure pub/sub dispatchers as master or slaves.

Understanding Implementing Master-Slave Dispatchers

This section provides an overview of implementing master-slave dispatchers

Master-Slave Dispatcher Processing

A slave dispatcher processes messages assigned to it by a master dispatcher.

A master domain allocates messages to a slave for processing when:

• The master detects that a slave dispatcher is active and not busy processing messages.

• The slave has an active channel on which the master is currently processing messages.

The dispatcher(s) processing in slave mode then process the allocated messages.

Master and slave dispatchers can reside on the same or on different machines.

You can create a domain consisting of only dedicated slave pub/sub servers. These servers register themselves as slaves, along with additional configurable information, such as the number of handlers booted, so that the appropriate master server can use that information to allocate work (messages to process) to the slave server(s).

You can configure any number of slave domains, however only one slave domain server will be allocated work per dispatch cycle. The master dispatcher looks into a slave pool, which contains all of the registered information about the slave domains and uses the first slave domain server that is available.

Slave Types

There are two types of dispatcher slaves:

Failover and Master-Slave Dispatchers

You can create a slave domain for use in domain failover.

The domain with the highest priority will become the active domain (master domain) in each group during failover. The next domain in priority will be programmatically configured as an active slave domain.

When a failover occurs the domain that failed will become inactive. The failover domain specified will go from an active slave to an active master. The next domain in priority will then become an active slave.

You can set failover for slave dispatchers. However, slave dispatchers cannot be part of any group and you cannot prioritize them.

See Setting Up Domain Failover.

Configuring Dynamic Slave Dispatchers

Use the Failover Configuration page in Integration Broker Monitor to configure dynamic slave dispatchers.

See Setting Up Domain Failover.

Configuring Static Slave Dispatchers

You use PSADMIN to specify a pub/sub dispatcher as master or slave by setting the following property:

See Also

Using the PSADMIN Utility

Configuring Integration Gateways for Load Balancing

This section discusses how to configure an integration gateways for load balancing.

Understanding Configuring Integration Gateways for Load Balancing

To increase gateway performance you can use load balancing. Load balancing involves the use of a third-party load balancing software product and the installation and configuration of multiple gateways. Then, when messages are sent or published to your messaging system, the load balancing software analyzes the load on installed gateways and determines to which gateway to send the messages to balance the load on all gateways.

For installation and configuration information about your load balancing software, please see the documentation that is included with the product.

Configuring Load Balancing

To configure gateways participating in load balancing, you must specify the URLs of the gateways in use for load balancing on the Gateways page, and then set integration gateway properties for each gateway you specify. Note that you can set different properties for each gateway.

To access the Gateways page, select PeopleTools, Integration Broker, Integration Setup, Gateways. Select the default local gateway.

To configure an integration gateway for load balancing:

1. Select the Load Balancer box.

2. In the Physical Gateway section, in the URL field, enter a gateway URL for a gateway that will be used for load balancing.

3. Click the plus (+) button and enter gateway URLs for each additional gateway to be used for load balancing.

4. Click the Save button.

5. For each gateway URL entered, click the Properties link to set integration gateway properties for that gateway.

See Also

Managing Integration Gateways