Investigating poor response times
Different system configurations and loads can lead to poor response times. Use the statistics provided by CICS® Transaction Gateway to identify possible causes of poor response times and improve them.
You can use the statistics that are generated by CICS Transaction Gateway to establish the reasons why response times might be poor. The following statistics contain advice for improving poor response times.
Investigate slow transaction response times in CICS
Slow transaction processing times in CICS cause increased response times. This can occur when a CICS system becomes constrained, or when interconnected database systems cause delays in transaction processing.Investigate CICS response times using CICS monitoring facilities and resolve any constraints that you find. Consider the setting of MAXTASK and TRANCLASS CICS server parameters.
Monitor the CICS TG statistics CS_IAVRESP and CSx_IAVRESP for each CICS server. If the value of CS_IAVRESP is higher than you anticipate for the transaction, a CICS server might be constrained, or interconnected database systems might be causing delays in transaction processing.
Worker thread queuing in the Gateway daemon
Transaction requests queue in the Gateway daemon due to high usage of worker threads. This can occur when the number of allocated connection managers is greater than the number of available worker threads.You can establish whether your worker threads have been queuing this is the case by considering the value in WT_ITIMEOUTS. If WT_ITIMEOUTS > 0 worker threads have been queuing. Also you can establish whether all your worker threads are in use by considering the value in WT_CCURR. If WT_CCURR = WT_CALLOC all worker threads are in use.
Increase the number of worker threads by amending the value of the maxworker configuration parameter to be equal to that of the number of connection managers. You might need to increase the EXCI pipe limits, see EXCI resource shortage. Consider reducing the value of the workertimeout configuration parameter if the queuing time is unacceptably high.
I/O errors during connection to the Gateway daemon
An insufficient number of configured connection managers in the Gateway daemon causes I/O errors in a remote client. This can occur when all available connection manager threads are allocated to remote clients.If CM_CALLOC = CM_SMAX all available connection manager threads are allocated to remote clients.
Increase the maximum number of connection managers by increasing the value of the maxconnect configuration parameter. Consider the maximum number of worker threads that you have defined.
Constraints in the network between the remote client and the Gateway daemon
The transmission of large amounts of data causes increased response times due to high network latency over the TCP/IP connection with the Gateway daemon. This can occur when large payloads, such as 32 KB COMMAREAs, are transmitted without the network payload being optimized using null truncation.If the response time at the remote client is higher than the value reported in GD_LAVRESP or GD_IAVRESP, there might be constraints in the network between the remote client and the Gateway daemon. If so select one or both of the following actions:
- Investigate and amend the network bandwidth.
- Modify your application design to optimize data flows by using COMMAREA null truncation, or by using the setCommareaOutboundLength() or setCommareaInboundLength() method. If your application is using containers, modify the design of the application to use smaller containers.
Constraints in the network between CICS Transaction Gateway and CICS
The transmission of large amounts of data causes increased response times due to network latency over the connection between CICS Transaction Gateway and CICS. This can occur when large payloads, such as 32 KB COMMAREAs, are transmitted without the network payload being optimized using null truncation.If GD_IAVRESP - CS_IAVRESP = a high value there might be constraints in the network between CICS Transaction Gateway and CICS. If so select one or more of the following actions:
- Investigate and amend the network bandwidth.
- Modify your application design to optimize data flows by using COMMAREA null truncation, or by using the setCommareaOutboundLength() or setCommareaInboundLength() method.
JVM stress causing poor performance in the Gateway daemon
In certain circumstances, the Gateway daemon can suffer poor performance if it spends a large proportion of its time allocating storage or performing garbage collection. This can occur if the default JVM heap size (128 MB) is used in an environment where large payloads (those greater than 16 KB) are in use and a large number of worker threads (more than 200) are in use concurrently.You can establish whether Gateway processing time is high by using the statistics GD_IAVRESP and CS_IAVRESP. If GD_IAVRESP-CS_IAVRESP > 100 milliseconds Gateway processing time is high.
You can establish whether connection managers are queuing for worker threads by using the statistics CM_IALLOCHI and WT_IALLOCHI. If (CM_IALLOCHI > WT_IALLOCHI) and WT_IALLOCHI > 0 connection managers are queuing for worker threads.
a. GC does not free at least 50% of the heap, that is
SE_CHEAPGCMIN/SE_SHEAPMAX > 50%
b. Time spent in GC is more than 10% of processing time, that is
SE_IGCTIME/1000/GD_IRUNTIME > 10%
c. Period between GC events is less than once per second, that is
GD_IRUNTIME/SE_IGCCOUNT < 1s 
Information