Benchmark testing of IMS Connect throughput

Answer

There are two aspects to solving the performance problem:

1. Changing the client code to issue a single send, rather than two sends of a complete single message. Two packages are being benchmarked. The IMS Connect Client issues two SENDs; one for X'54' bytes (llll and IRM), and one for X'F4' (Data and EOM). The client is more efficient doing one, not two sends. You can build two buffers of output, send the first and then send the second. There is no other processing being done between the two calls.
2. Changing the TCP/IP option from DELAYACK to NODELAYACK.
   The use of DELAYACK and NODELAYACK can be summarized as follows. This documentation will be added, along with other TCP/IP hints, in the IMS Connect Guide and Reference and has been made available in the PSP bucket:
   TCP/IP - NODELAYACK and DELAYACK

DELAYACK is used to minimize non-data transmissions from the host. The use of DELAYACK will result in the MVS TCP/IP delaying 200 ms before sending an ACK to the remote Server TCP/IP, unless the ACK is piggybacked on the host send of data from IMS Connect.
If the client code does a single SEND followed by a READ to the host, then the DELAYACK setting is valid and the ACK will be sent on the host output, and will not flow by itself.
If the Client does two or more SENDs followed by a READ to the host, then the host TCP/IP will delay 200 ms before sending an ACK for the data received, which will delay the sending of the next SEND of data from the client by at least 200 ms.

NODELAYACK is used to allow non-data transmissions from the host to flow without data. The use of NODELAYACK will result in the MVS TCP/IP sending an ACK immediately to the remote Server TCP/IP, and will not piggyback the ACK with host SEND of data from IMS Connect.
If the client code does a single SEND followed by a READ to the host, then the NODELAYACK setting is valid and the ACK will be sent by itself. If the Client does two or more SENDs followed by a READ to the host, then the host TCP/IP will send an ACK immediately for the data received, which will allow the next SEND of data from the Client to flow.
The following table is a guideline for the setting of DELAYACK or NODELAYACK for single Client SEND, and two consecutive Client SENDs (or multiple SENDs) preceding a Client READ, and provides an estimate for comparison of timing to receive all of the input from the single or two SENDs, in milliseconds. If more than two Client SENDs, the timing will be increased over that of two sends in the table below.

    | SINGLE SEND FOLLOWED  | TWO SENDS FOLLOWED                              
   | BY READ               | BY READ                                          
____|_______________________|___________________  

                        DELAYACK

    |     RECOMMENDED       |     RECOMMENDED                                                                    
   | SETTING      TIMING   | SETTING     TIMING                              
   |  YES        **36ms    |  NO          N/A                                
   |                       | (IF SELECTED 315ms)                              
____|_______________________|___________________

                        NODELAYACK  

    |     RECOMMENDED       |     RECOMMENDED
   | SETTING      TIMING   | SETTING     TIMING
   |  NO           N/A     |  YES          55ms
   | (IF SELECTED **38ms)  |                                                  
____|_______________________|____________________                          

KEY:
** These two values are so close that either setting would be valid, and in some cases the values could be reversed.
If your environment contains both Client Applications that do a single SEND followed by a READ as well as other Client Applications that do multiple SENDs followed by a READ, then you would want to set NODELAYACK, and not DELAYACK. You would only want to select DELAYACK if all Client Applications did a single SEND followed by a READ.
This setting can be set on the TCP/IP "PORT Statement" or on the "GATEWAY Statement".

The configuration and results of the benchmark test are:

CONFIGURATION:
8 servers
8 clients per server for total of 64 clients
1 IMS Connect port
Production IMSB system
64 Message regions

RESULTS:
Overall processing time was 88 ms
Peak TPS rate of 424
Rough breakdown of overall time
Server Processing 21 ms
Transport 17 ms
Ims Transaction 50 ms
Total 88 ms

Note that these a rough averages of the 600,000 transactions that were run during this test.