Resolving problems with performance

Use the advice given here to help you to resolve common problems with performance.

About this task

Scenario: You are experiencing problems with performance, such as:
- Poor response times in the IBM® Integration Toolkit when developing message flows
- Poor response time at deployment
- Individual messages taking a long time to process
- Poor overall performance, or performance that does not scale well
Solution: Possible solutions are:
- Tune the integration node
- Speed up WebSphere® MQ persistent messaging by optimizing the I/O (input/output)
- Speed up database access by optimizing I/O
- Increase system memory
- Use additional instances or multiple integration servers
- Optimize ESQL statements for best performance

A good source of information about performance is the set of reports in WebSphere MQ Family Category 2 (freeware) SupportPacs, available for download from the WebSphere MQ SupportPacs web page.

For more information, read Do you have a component that is running slowly?.

This topic contains advice for dealing with some common performance problems that can arise:

A WHILE loop in a large XML array takes a long time to process

Procedure

Scenario: A WHILE loop in a large XML array takes a long time to process.
Explanation: This problem arises when you use the CARDINALITY() function to determine the size of the array in the WHILE statement. With large arrays, the cost of determining the number of elements is proportional to the size of the array.
The CARDINALITY function is invoked each time the WHILE statement is executed. The message has many elements, therefore takes a long time to process when running the loop in this way.
Solution: Unless you have a message in which the number of elements of the array grows dynamically, determine the size of the array before entering the WHILE loop. Use code like the following example:
```
DECLARE i,c INTEGER;
SET i = 1;
SET c=CARDINALITY(OutputRoot.XMLNS.MyMessage.Array[ ]);
WHILE i <= c DO
      . . .
      . . .  loop processing
      . . .
END WHILE;
```

Message flow performance is reduced when you access message trees with many repeating records

Procedure

Scenario: Message flow performance is reduced when the following conditions are true:
- You are using ESQL processing to manipulate a large message tree.
- The message tree consists of repeating records or many fields.
- You have used explicit SET statements with field reference paths to access or create the fields.
- You have observed a gradual slowing of message flow processing as the ESQL processes more fields or repetitions.
Explanation: This problem occurs when you use field references, rather than reference variables, to access or create consecutive fields or records.
Consider the following example, in which independent SET statements use field reference paths to manipulate the message tree. The SET statement takes a source and target parameter, where either or both parameters are field references:
```
SET OutputRoot.XMLNS.TestCase.StructureA.ParentA.field = '1';
```
The problem arises when the SET statement is used to create many more fields, as shown in the following example:
```
SET OutputRoot.XMLNS.TestCase.StructureA.ParentA.field1 = '1';
SET OutputRoot.XMLNS.TestCase.StructureA.ParentA.field2 = '2';
SET OutputRoot.XMLNS.TestCase.StructureA.ParentA.field3 = '3';
SET OutputRoot.XMLNS.TestCase.StructureA.ParentA.field4 = '4';
SET OutputRoot.XMLNS.TestCase.StructureA.ParentA.field5 = '5';
```
In this example, the five fields that are created are all children of ParentA. Before the specified field can be created or modified, the integration node must navigate the named message tree to locate the point in the message tree that is to be altered. For example:
- To access field 1, the SET statement navigates to ParentA, then to the first field, therefore involving two navigations.
- To access field 5, the SET statement navigates to ParentA, then traverses each of the previous fields until it reaches field 5, therefore involving six navigations.
Navigating over all the fields that precede the specified field causes the loss in performance.
Now consider a scenario that accesses repeating fields in an input message tree; for example:
```
DECLARE myChar CHAR;
DECLARE thisRecord INT 0;
WHILE thisRecord < 10000 DO
	SET thisRecord = thisRecord + 1;
	SET myChar = InputRoot.MRM.myParent.myRepeatingRecord[thisRecord];
END WHILE;  
```
When index notation is used, as the count increases, the processing needs to navigate over all the preceding fields to get the one it wants; that is, it has to count over the previous records to get to the one that is represented by the current indexed reference.
- When accessing InputRoot.MRM.myParent.myRepeatingRecord[1], one navigation takes place to get to the first record.
- When accessing InputRoot.MRM.myParent.myRepeatingRecord[2], two navigations take place to get to the second record.
- When accessing InputRoot.MRM.myParent.myRepeatingRecord[N], N navigations take place to get to the N-th record.
Therefore, the total number of navigations for this WHILE loop is: 1 + 2 + 3 + .... + N, which is not linear.
Solution: If you are accessing or creating consecutive fields or records, use reference variables.
When you use reference variables, the statement navigates to the main parent, which maintains a pointer to the field in the message tree. The following example shows the ESQL that can be used to reduce the number of navigations when creating new output message tree fields:
```
SET OutputRoot.XMLNS.TestCase.StructureA.ParentA.field1 = '1';
DECLARE outRef REFERENCE TO OutputRoot.XMLNS.TestCase.StructureA.ParentA;
SET outRef.field2 = '2';
SET outRef.field3 = '3';
SET outRef.field4 = '4';
SET outRef.field5 = '5';
```
When referencing repeating input message tree fields, you could use the following ESQL:
```
DECLARE myChar CHAR;
DECLARE inputRef REFERENCE TO InputRoot.MRM.myParent.myRepeatingRecord[1];
WHILE LASTMOVE(inputRef) DO
	SET myChar = inputRef;
	MOVE inputRef NEXTSIBLING NAME 'myRepeatingRecord';
END WHILE;
```
For further information, see Creating dynamic field references.

You are experiencing poor performance in the IBM Integration Toolkit when working with large projects

Procedure

Scenario: You are experiencing poor performance in the IBM Integration Toolkit when working with large or complex projects.
Explanation: Performance is reduced because of frequent project changes, such as adding and removing projects, or using Project > Clean. Complete project updates use large amounts of memory due to the size, number, and connections between files.
Solution: Increase your system memory.

Performance is reduced when you run web services with small message sizes

Procedure

Scenario: You see poor response times and throughput rates when you run web services using HTTP, and send smaller messages sizes (typically less than 32 KB). Throughput rates can fluctuate with message size. IBM Integration Bus running on the AIX® platform might be affected.
Explanation: The default configuration of HTTP enables the Nagle algorithm, which seeks to improve the efficiency of Internet Protocol networks by reducing the number of packets sent. It works by buffering small packets together, creating a smaller number of large packets. By default, the tcpnodelay setting on the sockets of the HTTPRequest is true. You can disable the Nagle algorithm at either the operating system level (system wide) or through IBM Integration Bus (affecting only the IBM Integration Bus HTTP sockets).

Solution: Use the following commands to disable the Nagle algorithm:

HTTPRequest, SOAPRequest, and SCARequest nodes

mqsichangeproperties integrationNodeName -e integrationServerName 
      -o ComIbmSocketConnectionManager -n tcpNoDelay -v true|false
mqsichangeproperties integrationNodeName -e integrationServerName 
      -o ComIbmSocketConnectionManager -n tcpNoDelaySSL -v true|false

Embedded listener for HTTPReply, SOAPReply, and SCAReply nodes

mqsichangeproperties integrationNodeName -e integrationServerName 
      -o HTTPConnector -n tcpNoDelay -v true
mqsichangeproperties integrationNodeName -e integrationServerName 
      -o HTTPSConnector -n tcpNoDelay -v true

HTTP Listener for HTTPReply, SOAPReply, and SCAReply nodes

mqsichangeproperties integrationNodeName -b httplistener 
      -o HTTPConnector -n tcpNoDelay -v true|false
mqsichangeproperties integrationNodeName -b httplistener 
      -o HTTPSConnector -n tcpNoDelay -v true|false

To determine the value set, take the following steps:

Report property values

Use the following command:

mqsireportproperties integrationNodeName -e integrationServerName 
      -o ComIbmSocketConnectionManager -r
mqsireportproperties integrationNodeName -e integrationServerName 
      -o HTTPConnector -r
mqsireportproperties integrationNodeName -e integrationServerName 
      -o HTTPSConnector -r
mqsireportproperties integrationNodeName -b httplistener 
      -o HTTPConnector -r
mqsireportproperties integrationNodeName -b httplistener 
      -o HTTPSConnector -r