Tuning the Gateway

You can tune the performance of your system by modifying values such as the number of connection manager threads and worker threads. Other values can also be modified to improve performance.

The default values that have been chosen for configuration and tuning aim to give a compromise between:

The following factors affect performance; you might need to alter the default configuration to suit your system environment:

Connection manager threads

If the value specified for Initial number of connection manager threads is too high, your system will waste resources managing the threads that are not needed. See Initial number of connection manager threads for more information.

If the value for Maximum number of connection manager threads is too low to meet all requests from applications, each new request that requires a connection manager thread must wait for a thread to become available. If the waiting time exceeds the value specified in the Connection timeout parameter, the CICS Transaction Gateway refuses the connection. See Maximum number of connection manager threads for more information.

The design of your applications determines the number of connection manager threads you need. Incoming connections to CICS Transaction Gateway could be from a servlet, with each copy of the servlet issuing its own ECI requests, but sharing a single connection manager thread. Alternatively, the application might create a pool of connections, and ECI requests could be issued onto any connection from the pool.

CICS Transaction Gateway creates a new TCP/IP connection, each time a Java™ client side application creates a new JavaGateway object. This means that system performance is better if your applications issue many ECI requests using the same JavaGateway object, and from within the same thread, than if they create a new JavaGateway object for each request.

Flowing multiple requests through the same JavaGateway object also reduces the system resources required to create, and to destroy, JavaGateway objects.

Worker threads

Worker threads handle outbound connections between CICS Transaction Gateway and your CICS server. The design of your applications, and the workload that you need to support, affects the number of worker threads you need: the longer your CICS transactions remain in process, the more worker threads you need to maintain a given transaction rate.

If the value specified for Initial number of worker threads is too high, CICS Transaction Gateway uses resources to manage threads that it does not need.

If the value is too low, CICS Transaction Gateway uses resources to search for available worker threads.

See Initial number of worker threads for more information about the Initial number of worker threads setting.

When using ECI to call the same CICS program, you can estimate the number of worker threads you need to support a given workload by multiplying the following values:

  • The number of transactions per second passing through CICS Transaction Gateway.
  • The average transaction response time through CICS Transaction Gateway in seconds. You can use the CS_LAVRESP statistic to calculate this response time.

An MVS™ address space cannot open more than the maximum number of EXCI pipes set by CICS. This means that you cannot improve performance by specifying a value greater than that set by CICS for Maximum number of worker threads. However, if your CICS transactions remain in process for a long time, all of the EXCI connections could become busy, leaving no worker threads available.

You can increase performance by starting multiple gateways; see Starting multiple CICS Transaction Gateways.

Display TCP/IP host names

Selecting this option might cause severe performance reduction on some systems. See Display TCP/IP host names.

Timeout values

It is unlikely that you can improve performance by changing the default timeout values. However, you might need to change them for particular applications. See Configuring Gateway daemon settings for more information on these configuration parameters.

Connection logging

The Gateway configuration setting, Log Client connections and disconnections, controls whether or not CICS Transaction Gateway writes a message each time that a client application program connects to, or disconnects from, the Gateway daemon. The default is for these messages not to be written. Selecting this setting can significantly reduce performance, especially in a system where client application programs connect and disconnect frequently. See Log Client connections and disconnections.

Local mode

Design your system configuration to use local mode communication between components wherever possible.

In local mode, WebSphere® Application Server and the CICS Transaction Gateway are installed on the same z/OS® image. Calls to the CICS Transaction Gateway are made using a local protocol. This allows calls from the CICS resource adapters to go directly to the CICS Transaction Gateway JNI layer.

Remote mode

In remote mode, all calls to the CICS Transaction Gateway are made using a standard network protocol such as TCP or SSL. This will happen even if WebSphere Application Server and the CICS Transaction Gateway are installed on the same machine. If your configuration has components running in remote mode, additional service provider daemons will be running to process and forward requests between components. These extra demands on the system can have an adverse effect on performance.


Information Information

Feedback


Timestamp icon Last updated: Wednesday, 27 August 2014


https://ut-ilnx-r4.hursley.ibm.com/tgzos_latest/help/topic/com.ibm.cics.tg.zos.doc//performance/topics/ccl99ce.html