CICS HTTP support: Performance and tuning

What affects the limit on the number of HTTP connections

Several aspects of your CICS region configuration can affect the maximum number of HTTP connections the region can support:

Storage available in the CICS region

In practical terms, the number of connections that can be active between a single CICS region and the web is primarily limited by the storage available in the CICS region. Storage requirements for CICS web support explains the most significant storage requirements for CICS web support activities.

Effect of the MXT setting

In each CICS region, the maximum number of concurrent connections between CICS as an HTTP server and web clients, or between CICS as an HTTP client and a server on the web, can in theory be up to 64,000. The MXT setting does not directly limit the number of concurrent connections:

• For CICS as an HTTP server, the CWXN transaction (web attach task) does not remain in the system for the duration of a persistent connection, but terminates after each request for which it was required. This means that between requests, a persistent connection can exist, being monitored by the Sockets listener task (CSOL), without being associated with an active task.
• For CICS as an HTTP client, an application program can open and maintain more than one persistent connection to a server on the web, and these are covered by the single active task for the application program.

However, the MXT setting, and any limitations that you set in the transaction class definitions for CICS web support transactions, can be used to limit the amount of CICS web support activity in the CICS region. For information about how to set MXT, see Setting the maximum task specification (MXT).

Using performance tuning for HTTP connections to protect CICS from unconstrained resource demand

The SOTUNING SIT parameter specifies whether performance tuning for HTTP connections occur to protect CICS from unconstrained resource demand. If the SOTUNING SIT parameter is set to the default value of YES, if the region becomes overloaded CICS temporarily stops listening for new HTTP connection requests. If overloading continues, CICS closes existing HTTP persistent connections and marks all new HTTP connections as non-persistent. These actions prevent oversupply of new HTTP work from being received and queued within CICS, allowing feedback to TCP/IP port sharing and Sysplex Distributor, promoting a balanced sharing of workload with other regions that are sharing the same IP endpoint and allowing the CICS region to recover more quickly. If SOTUNING is set to YES, CICS periodically closes persistent connections to allow more efficient sharing of workload across regions that share IP endpoints, using technologies such as TCP/IP shared ports and Sysplex distributor.

CICS TCP/IP statistics can be used to illustrate whether performance tuning has taken place. For more information, see Performance tuning statistics.

Performance considerations for CICS as an HTTP server

What affects performance

Priority of transactions is significant

For CICS as an HTTP server, the priority of the various transactions involved for CICS web support is significant, and incorrect settings might lead to a short-on-storage situation. Priorities for CICS web support transactions (CWXN, CWXU, CWBA, CW2A) tells you how to set priorities to avoid issues in this area.

Types of HTTP responses influence performance

For CICS as an HTTP server, HTTP responses can be generated by an application, or provided from a static document, which can be either an zFS file or a CICS document template. A CICS document template can be one of a variety of different CICS resources, including a program, a partitioned data set, or a file. Relative performance of CICS web support response methods explains the differences in performance between these response types.

How to improve performance

Connection throttling can prevent a CICS region from being overloaded

By default, CICS attempts to keep HTTP connections open as persistent connections. Persistent connections between a web client and a server can be reused for more than one exchange of a request and a response, so a new connection does not have to be established for each request. Persistent connections improve network performance because compared with making a request use an existing connection, establishing a new connection consumes significant additional network resources. However, if multiple web clients set up long-lived persistent connections to CICS as an HTTP server and use the connections heavily, it is possible for a CICS region handling the connections to become overloaded and experience performance problems.

If you experience such problems, you can set up connection throttling to make excess web clients connect to other CICS regions that share the port and provide the same service.

• Use the MAXPERSIST attribute on the TCPIPSERVICE resource definition to set a limit on the number of persistent HTTP connections that a CICS region accepts for a particular port. Subsequent web clients are subject to connection throttling, and are required to close their connection after each response. When the new clients reconnect, if they connect to another CICS region that shares the port and has not reached its limit they can maintain a persistent connection there.
• An HTTP/1.1 server should normally allow persistent connections, so only set up connection throttling in a CICS region that has experienced performance problems due to long-lived persistent connections. If you do limit the number of persistent connections, CICS as an HTTP server is still compliant with the HTTP/1.1 specification (provided that you do not set a zero limit), but refusing persistent connections is not recommended as a normal practice.
• Be aware that the performance of web clients can be affected when they fail to obtain a persistent connection that they expected, especially if they reconnect to the CICS region where connection throttling is in place. The performance returns to normal when the web clients connect to another CICS region that shares the port and has not reached its limit.

For more information about persistent connections and connection throttling, see How CICS web support handles persistent connections.

CICS TCP/IP statistics can be used to illustrate how well connections are reused. For more information, see Connection persistence statistics.

Performance considerations for CICS as an HTTP client

How to improve performance

Connection pooling can provide performance benefits in some situations

For CICS as an HTTP client, by default CICS closes client HTTP connections after an application has finished using the connection. If you set up connection pooling, CICS can leave the connection open and place it in a pool in a dormant state, and it can be reused by the same application or by another application that connects to the same host and port. Connection pooling for HTTP client performance explains the situations in which connection pooling provides performance benefits for CICS web support applications and web services applications.

Performance considerations for SSL connections

• If you are using the Secure Sockets Layer (SSL), the security measures (such as encryption and decryption and the SSL handshake) cause a slight increase in CPU per transaction. For CICS as an HTTP client, if you implement connection pooling CICS applications can reuse client HTTP connections that have already been made using SSL. The security measures do not need to be repeated when the connection is reused, so applications that are given a connection from the pool do not experience this CPU increase.
• You can monitor the cipher suites that are being selected for SSL connections between each CICS region and its clients. The performance data field SOCIPHER (320) in the DFHSOCK group shows the code for the cipher suite that was used for each SSL inbound connection. Use this information to identify any cipher suites that are offered by the CICS region but are not being selected for SSL connections. You can also identify any less efficient or less secure cipher suites that are being selected for SSL inbound connections but that you would prefer to eliminate. Customizing encryption negotiations explains how to customize the list of cipher suites that can be used in encryption negotiations.
• SSL uses S8 TCBs. For HTTP requests over SSL, all CICS processing occurs on the S8 TCB (there is no switching between the S8 and SO TCBs). This means that the web attach task (CWXN by default) will stay on the S8 TCB until all the data has been sent or received. This could result in the task that is sending or receiving the messages hitting the runaway limit and being terminated. If sending or receiving large messages, you should determine if you need to increase the transaction RUNAWAY value for the web server HTTP attach transaction (CWXN by default), the web server alias transactions, and any transactions that issue the Web client API commands SEND, RECEIVE and CONVERSE.

  You can monitor S8 TCBs using the dispatcher TCB statistics.

  See CICS dispatcher: performance and tuning for guidance on setting the system initialization parameters that control the number of TCBs that CICS uses.