Performance tuning

You can influence the performance of the services that run within an FTM SWIFT instance.

Message flow topology

The way you deploy the various message flows to an message broker can influence the throughput and the storage consumption of your FTM SWIFT environment.

Message throughput

With the standard setup, you might notice that the FTM SWIFT services do not fully utilize your processor. This is not necessarily a bad thing, because you might want to reserve processor capacity for other applications that are running on the same system. However, if high message throughput is important, you might want to modify your setup to exploit surplus processor capacity. One way to increase message throughput is to deploy message flows several times. There are two ways to do this:

Increase the number of instances counter for a message flow when you configure your BAR file. This increases the number of instances of this message flow within one execution group.
Deploy the same message flow in several different execution groups.

SIPN FIN and FMT FIN

For FIN message traffic, the relevant message flows are:

DNF_ILC_FIN
DNF_ILS_FIN
DNF_ILS_ACK

To increase message throughput, you can increase the number of instances of these message flows within one execution group, or deploy the flows several times in separate execution groups. Deploying these message flows to several execution groups is slightly more effective, but has the disadvantage that it increases memory consumption. Consequently, the best solution is to use your standard execution group layout and add message flows to existing execution groups. If that is not sufficient, increase the instance counter within an execution group.

To find the optimum number of times to deploy a message flow, conduct performance tests. In general, it is a good idea to start with a configuration in which all message flows are deployed the same number of times. During performance testing, monitor the input queues of the various message flows. If a message flow is found to be a bottleneck, add another instance of that message flow.

The following message flows are also affected by FIN message traffic:

DNI_R_AUDIT: If you record message audit data at the FSM layer, the DNI_R_AUDIT message flow might have difficulty keeping up with the message volume. If so, increase the number of times that the DNI_R_AUDIT message flow is deployed.
DNI_R_MWH: If you store FIN messages in the message warehouse, the DNI_R_MWH message flow might have difficulty keeping up with the message volume. However, deploying the DNI_R_MWH message flow more than once is not allowed, because doing so would cause errors.

MSIF

For MSIF message and file traffic scenarios, the relevant message flows are:

DNF_O_FT
DNF_O_FT1
DNF_O_FT2
DNF_O_FT3

The following refers to a flow out of this list as DNF_O_FTx.

Before tuning an individual flow, consider to separate your business traffic to dedicated DNF_O_FTx services and thus decouple the processing of message-transfer or file-transfer scenarios with distinct business requirements. This enables you to tune the flows for each service individually. For more information about exploiting more than one DNF_O_FTx service, see the description for MSIF transfer services in .

If the MSIF transfer service DNF_O_FTx that you are about to tune is processing:

InterAct transfers

You can increase the number of flow instances of DNF_O_FTx within one execution group, or deploy DNF_O_FTx several times in separate execution groups. Deploying flows to several execution groups is slightly more effective, but has the disadvantage that it increases memory consumption. Consequently, the best solution is to use your standard execution group layout and add DNF_O_FTx message flows to existing execution groups. If that is not sufficient, increase the flow instance counter within an execution group. To find the optimum number of times to deploy DNF_O_FTx and the number of flow instances for it, conduct performance tests.

FileAct transfers

MSIF needs to do file I/O operations in several situations, for example to transfer a file from the host to the SAG, or compress its contents. The execution time for such an operation significantly depends on the file size. To decouple file I/O operations from FileAct protocol handling and consequently to avoid time-outs, increase the number of flow instances of DNF_O_FTx within one execution group to 2.
If scalability of file transfers is important, deploy DNF_O_FTx to separate execution groups and increase the number of flow instances within each execution group to 2. Deploying DNF_O_FTx several times in separate execution groups is significantly more effective for file transfers than using several flow instances within one execution group.

To find the optimum number of times to deploy DNF_O_FTx, conduct performance tests. Also take into account that:

Often, when transferring files, the bottleneck is not within FTM SWIFT, but in the SAG or SIPN. Deploying DNF_O_FTx several times can be effective only if your SAGs have surplus capacity and your SIPN lines have sufficient bandwidth.
Each SAG has a limited number of FileAct client processes. This number is specified when you order the SAG from SWIFT.
If the number of FileAct client processes are exhausted, FTM SWIFT buffers FileAct requests. For more information about how it does this, see the description of the FileWindowSize option in SAG communication options: SagCommOptions.
If you use SWIFTNet 7.0:
One SNL can handle at most 30 file transfers concurrently. This number cannot be changed. If you require more concurrent transfers, you will require additional SAGs.

Configuring FTM SWIFT for better performance

Changing the values of certain configuration parameters can improve performance.

Tracing

An overly detailed trace level reduces performance:

Issue the following command to determine how your trace levels are set:
```
list -ou SYSOU -ct DniLevelsTrace -lo NCOSV
```
If there are any COs of type DniLevelsTrace other than DNI, DNF, or DNQ for which the trace level is set to Debug or Informational, remove them:
```
rem -ou SYSOU -ct DniLevelsTrace -co coName
```

Set the levels of the COs of type DniLevelsTrace with the names DNI, DNF, DNP, and DNQ to Warning:

add -ou SYSOU -ct DniLevelsTrace -co DNI -attr Level -val Warning
add -ou SYSOU -ct DniLevelsTrace -co DNF -attr Level -val Warning
add -ou SYSOU -ct DniLevelsTrace -co DNP -attr Level -val Warning
add -ou SYSOU -ct DniLevelsTrace -co DNQ -attr Level -val Warning

Commit, apply, and deploy any changes:

com -ou SYSOU
app –ou SYSOU
dep -ou SYSOU

Message audit data

Determine for which messages audit data is collected and whether this data collection negatively affects performance.

Turning off the collection of message audit data

Collecting audit data for messages is often required for business reasons; however, it is not always required, and it is expensive. When an FTM SWIFT instance is newly customized, all message audit points are switched on. To improve performance, switch off the collection of message audit data where it is not needed:

To find your current message audit settings, issue the following command:
```
list -ou % -ct DniOptionsMsgAudit -lo NCOSV
```
Table 1 describes which CO of type DniOptionsMsgAudit corresponds to a particular service. Some services offer several audit points. Consider carefully whether you need several audit records for a single message transfer.
To switch off the collection of message audit data where it is not needed, issue the following command for the corresponding CO of type DniOptionsMsgAudit:
```
add -ou ouName -ct DniOptionsMsgAudit -co coName -attr DniFlagMsgAudit -val No
```

Commit, apply, and deploy any changes:

com -ou ouName
app –ou ouName
dep -ou ouName

Suppressing storage of MQRFH2 headers

Recording message audit data causes the complete message, including its body and MQRFH2 header, to be stored in a DB2® table:

The body contains the business message.
The MQRFH2 header contains message processing information, including history information.

For messages that are processed by the SIPN FIN, FMT FIN, and MSIF services, consider carefully whether you need to store their MQRFH2 headers. Electing not to store MQRFH2 headers reduces both processor and data storage requirements.

To switch off the storing MQRFH2 headers:

Refer to Table 1 to determine which CO of type DniOptionsMsgAudit corresponds to a particular service.

Issue the following command for the corresponding CO of type DniOptionsMsgAudit:

add -ou ouName -ct DniOptionsMsgAudit -co coName -attr DniFlagSaveMQRFH2 -val No

Commit, apply, and deploy any changes:

com -ou ouName
app –ou ouName
dep -ou ouName

Message warehouse

Like recording message audit data, storing information in the message warehouse is also expensive. You might want to verify that only those message warehouse recording points that are truly needed are switched on:

To display your current message warehouse settings, issue the following commands:
```
list -ou % -ct DnfOptionsMwh -lo NCOSV
list -ou % -ct DnfEfaOptionsMwh -lo NCOSV
list -ou % -ct DnqOptionsMwh -lo NCOSV
```
Recording data in the message warehouse describes which COs corresponds to each service.

To switch off message warehouse recording for a particular CO, issue whichever of the following commands corresponds to its type:

add -ou ouName -ct DnfOptionsMwh    -co coName -attr DnfFlagMwh -val No
add -ou ouName -ct DnfEfaOptionsMwh -co coName -attr DnfFlagMwh -val No
add -ou ouName -ct DnqOptionsMwh    -co coName -attr DnqFlagMwh -val No

Commit, apply, and deploy any changes:

com -ou ouName
app –ou ouName
dep -ou ouName

Trusted FIN applications

When processing FIN messages, a large amount of processor time is spent checking authorization, that is, checking whether the user ID of the MQ request message was assigned the SWIFTNetFINSender role or an equivalent role. If your system setup ensures that only trusted applications can send SWIFTNet FIN requests to FTM SWIFT, this authorization check is not needed.

To switch off authorization checking:

Issue the following command on a single line:

add -ou ouName -ct DnfFinParametersSnfil 
    -co DnfFinParametersSnfil -attr DnfAccessControlSnfil 
    -val None

Commit, apply, and deploy any changes:

com -ou ouName
app –ou ouName
dep -ou ouName

Improving data deployment configuration

Whenever you change or delete configuration data, the original data is preserved so that you can query the history of configuration changes. If the deploy command for configuration data becomes too slow (that is, if it takes a long time for configuration changes to become active), you might want to archive and purge this old configuration data.

To determine whether it is necessary to purge data, ask someone with DB2 administrator rights or the SELECT right for the DNI_OU table to issue the following SQL statement (replace DNIvSN with the schema name of your FTM SWIFT instance):

WITH OU_LIST (OU_NAME, NUM_LEVELS)
 AS
  (SELECT OU_NAME,
          COUNT(1) AS NUM_LEVELS
     FROM DNIvSN.DNI_OU
     WHERE OU_LEVEL_LCSTATUS='DP'
   GROUP BY OU_NAME
  )
SELECT OU_NAME, NUM_LEVELS AS TOP_NUM_LEVELS 
  FROM OU_LIST     AS OUS
  WHERE NUM_LEVELS = (SELECT MAX(NUM_LEVELS)
                        FROM OU_LIST
                     )
;

This statement reports the name of the OU that has the highest number of configuration change levels. If this number exceeds 100, it is usually a good idea to archive and purge the configuration data for that OU. How to do this is described in Saving and purging configuration and security data.

Configuring the printing service

Order sizes should not be excessively large or small:

Processing large print orders requires significant system resources, not only processor time, but also DB2 and MQ resources such as locks and log space. Therefore, when configuring print queues, do not specify an excessively large order size. Order sizes larger than 1000 are not recommended.
Alternatively, processing a print order carries certain fixed costs, and processing an order that contains only a single message is relatively expensive. So, if possible, also avoid using very small order sizes.

Implementing routing rules

Each FTM SWIFT message contains at least one header (the MQRFH2 header) and a body:

The MQRFH2 header is in an XML format.
The body typically contains either a FIN message in MTFIN format or an InterAct message in MX format.

Message routing entails parsing an FTM SWIFT message so that its contents can be compared with routing criteria specified in the routing flow.

Implementing routing rules for FIN messages

FTM SWIFT provides a node that can be used to transform a FIN message from MTFIN format into an XML format called MTXML, which is easier for the broker to parse. The MTXML format is required for messages that are processed by the following services:

The print service
The Message Entry and Repair Facility

However, for other services, because transforming a FIN message from MTFIN to MTXML is expensive, it should be avoided if possible. For example:

Sometimes routing can be based entirely on data in the MQRFH2 header, which is already in an XML format. If so, there is no need to transform the message body to MTXML.
Sometimes routing for some messages can be based on data contained in MQRFH2, and only a subset of messages need to be transformed. If so, make as many routing decisions as possible before transforming messages to MTXML, and transform only those messages that require it.

After a FIN message is transformed from MTFIN to MTXML, if the MTXML version is modified during routing, FTM SWIFT must create an MTFIN version of the modified message when the message leaves the routing flow. The transformation from MTXML to MTFIN format is just as expensive as the transformation in the opposite direction. Therefore, if possible, avoid modifying messages after they were transformed to MTXML.

Implementing routing rules for MX messages

MX messages are already in XML format, and so do not need to be transformed. However, MX messages often have a large and complex structure, which can make them time consuming to process. Fortunately, during routing, a broker parses only as much of each message as is necessary to locate the field referred to by a routing condition. Therefore, when designing routing flows for MX messages, specify first those routing criteria that address fields that appear early in the message. This minimizes the amount of parsing required, which in turn improves overall performance.

IBM Integration Bus setup

The most important measures to control the memory consumption of the IBM Integration Bus and FTM SWIFT are:

If you use the nodes provided by FTM SWIFT in your own message flows (for example, for custom routing flows), increase the Java™ stack size in the corresponding execution groups.
If you use the MSIF transfer service to transfer files, check the jvmMinHeapSize and jvmMaxHeapSize properties in the execution groups in which the MSIF message flows are deployed.

DB2 related tuning

Performance can be improved by running RUNSTATS and REORG regularly on the table spaces storing configuration and security administration data:

DNICOS
DNICOSCC
DNICT
DNICTA
DNICTAV
DNIDBHIS
DNIOU
DNIRG
DNIRGR
DNIROA
DNIROLE
DNIROR
DNIURG
DNIURV
DNIUSR
DNIUSRRO

Run RUNSTATS particularly after making significant configuration changes, for example:

After setting up a new environment
After migrating to a new FTM SWIFT release
After changing a large number of security settings such as role or role group assignments

To run RUNSTATS, use the following ddl module:

deployment_dir/instance/admin/dnixzrst.ddl

where deployment_dir represents your deployment directory. The default deployment directory is:

/var/ftmswift_v300/cus/depdata