Tuning Messaging System Performance

This chapter discusses how to:

• Throttle dispatched messages through the messaging system.

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

• Implement master-slave dispatchers.

• Configure integration gateways for load balancing.

• Implement load balance on service operation queues.

• Resubmit failed transactions.

• Utilize data mover scripts for large service operation notifications.

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 the Service Operations Monitor.

See Also

Viewing 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 Queue 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

Multi-threading allows you to send a group of synchronous requests 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 asynchronous message publications 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.

See Also

Exception Handling for Synchronous Message Processing

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);

The IntBroker object is responsible for managing the messages, instantiation of the SyncRequest handler and calling the Send method for each request. The IntBroker object then polls the SyncRequest handler object to determine when all processing is complete. At that time, status and error checking is performed and the response message objects are created. The response messages are packaged as an array and returned to the calling method.

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();

Exception Handling for Synchronous Message Processing

When a an outbound synchronous request fails you can throw a framework exception leading to a message box error and subsequent component roll back of the transaction.

Note. This type of exception handling applies to outbound synchronous requests only, including outbound multi-threaded synchronous requests.

For example, if 10 synchronous requests are performed in parallel (threaded sync request), you have the option to select the User Exception check box on the routing definition for the service operation. When the User Exception check box is selected, if any of the synchronous requests error, the component is not rolled back. You can check each synchronous request to determine if there is an error and actually read the associated error message. You can then throw an exception or go on to process the next synchronous request in the array.

See Managing Routing Definitions.

The following example shows sample pseudo PeopleCode to read the exception:

Local Rowset &FLIGHTPLAN, &FLIGHTPLAN_RETURN;
Local array of Message &messages;
Local array of Message &return_mesages;

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

QE_FLIGHTDATA.QE_ACNUMBER.Value = QE_FLIGHTDATA.QE_ACNUMBER + 1;

&FLIGHT_PROFILE = GetLevel0();

&rs1 = &FLIGHT_PROFILE.GetRow(1).GetRowset(Scroll.QE_NAVIGATION);
&rs2 = &FLIGHT_PROFILE.GetRow(1).GetRowset(Scroll.QE_RADAR_PRESET);
&rs3 = &FLIGHT_PROFILE.GetRow(1).GetRowset(Scroll.QE_ARMAMENT);
&messages [1] = CreateMessage(Operation.SYNC_PARTS);

For &i = 1 To &messages [1].PartCount
   
   If &i = 1 Then
      &rs1.CopyTO(&messages [1].GetPartRowset(&i));      
   End-If;
   
   If &i = 2 Then
      &rs2.CopyTO(&messages [1].GetPartRowset(&i));    
   End-If;
   
   If &i = 3 Then
      &rs3.CopyTO(&messages [1].GetPartRowset(&i));
   End-If;
   
End-For;

&messages [2] = CreateMessage(Operation.SYNC_PARTS);

For &i = 1 To &messages [2].PartCount
   
   If &i = 1 Then
      &rs1.CopyTO(&messages [2].GetPartRowset(&i));
   End-If;
   
   If &i = 2 Then
      &rs3.CopyTO(&messages [2].GetPartRowset(&i));
   End-If;
   
   If &i = 3 Then
      &rs2.CopyTO(&messages [2].GetPartRowset(&i));
   End-If;
   
End-For;

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

If &return_mesages [1].ResponseStatus = %IB_Status_Success Then
   
   For &i = 1 To &return_mesages [1].PartCount
      
//perform local processing on response data

   End-For;
   
Else
   
   &nMsgNumber = &return_mesages [1].IBException.MessageNumber;
   &nMsgSetNumber &return_mesages [1].IBException.MessageSetNumber;
  &exceptString = &return_mesages [1].IBException.ToString();
// Evaluate exception and throw error if necessary
   
End-If;

If &return_mesages [2].ResponseStatus = %IB_Status_Success Then
   
   For &i = 1 To &return_mesages [2].PartCount
      
  //perform local processing on response data   End-For;
   
  Else
   
   &nMsgNumber = &return_mesages [2].IBException.MessageNumber;
   &nMsgSetNumber &return_mesages [2].IBException.MessageSetNumber;
  &exceptString = &return_mesages [2].IBException.ToString();

// Evaluate exception and throw error if necessary
   
End-If;

Implementing Master-Slave Dispatchers

Master-slave dispatching is where a master domain allocates messages to one or more slave dispatchers for processing. 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 service operations assigned to it by a master dispatcher.

A master domain allocates service operations to a slave for processing when:

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

• The slave has an active queue on which the master is currently processing service operations.

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

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 (service operations to process) to the slave server(s).

The master domain can allocate work to one or more slave domains.

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 becomes 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 becomes inactive. The failover domain specified goes from an active slave to an active master. The next domain in priority then becomes 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 the Service Operations 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

Implementing Load Balancing on Service Operation Queues

This section discusses implementing load balancing on service operation queues.

Understanding Implementing Load Balancing on Service Operation Queues

PeopleSoft provides the ability to load balance queue processing on active pub/sub systems using the Load Balance Interval parameter in PSADMIN.

Note. The Load Balance Interval parameter is the same parameter used to resubmit failed transactions.

For example, without the Load Balance Interval parameter set, if there are three queues that have service operations to process, only one queue gets processed at a time. Moreover, as TPA calls continue to be generated, the dispatcher looks in the same queue to process service operations, resulting in that single queue performing most of the processing. This scenario happens most frequently when publishing in batch mode. As long as there are service operations in that one queue, the system does not process any service operations in any other queue.

However, when you set the Load Balance Interval parameter and the value you set is exceeded, the system dispatches all queues. This means that other queues that can be processed will be processed, at least partially, for the interval time designated.

See Also

Specifying Dispatcher Parameters

Setting the Load Balance Interval Parameter

The Load Balance Interval parameter is located in the Settings for Pub/Sub Servers section of PSADMIN. By default this feature is disabled and has a default setting of 0. The value you set is the number of minutes between load balance processing.

See Also

Using the PSADMIN Utility

Resubmitting Failed Transactions

The PSADMIN parameter Load Balance Interval enables you to resubmit failed transactions for processing.

This functionality allow transactions that failed due to a connection problem to be retried periodically. The benefit of this is to unblock a queue and have it be able to process in a more load balancing way.

Note. The Load Balance Interval parameter is the same parameter used to implement load balancing on message queues.

The Load Balance Interval parameter is located in the Settings for Pub/Sub Servers section of PSADMIN. The value you set for the Load Balance Interval parameter determines the time interval (in minutes) between load balance processing when the dispatcher is processing requests.

When this parameter is enabled, processing consists of attempting to perform the equivalent using the Scan Interval parameter, without the delay. Moreover, when this load balance interval is reached the equivalent of the scan interval processing is performed on all default dispatchers, allowing other queues to process transactions.

When true scan interval processing is performed the load balance interval time is reset.

Note. Only the default publication contract dispatcher (_dflt) is used to ping these nodes. When the load balance interval is exceeded the default publication contract dispatcher performs the scan interval processing of pinging the nodes. If the actual scan interval processing is run before the load balancing interval is exceeded, then the system resets the load balance time value.

See Also

Setting the Load Balance Interval Parameter

Specifying Dispatcher Parameters

Utilize Data Mover Scripts for Large Message Subscriptions

PeopleSoft Integration Broker provides a DMS handler type that serves as a bulk loader to insert data. This handler is available when working with asynchronous one-way service operation types that contain rowset-based messages.

The DMS handler performs destructive bulk inserts. This means that the data will first be deleted then the insert of the data will be performed. If the event fails the data is not rolled back.

See Adding Handlers to Service Operations.