Region performances

The server pool size is number of transaction server processes which carry out all the transactional work activated by the on-line connections (terminals) and deeply affects the performance of the region.

When a transaction is requested, XCICS/TS assigns the task to the first process in pool available. If no process is available, it puts the request in the "Wait Queue" (WQ), waiting for a server process to become available.

Since the number transaction server processes (pool size) determines the number of concurrent task that can run on a region, underestimating it can cause online transaction to wait in the WQ, and, if transactions are waiting, so are users. Therefore, you need to allocate enough transaction server processes to keep the WQ at a maximum of 2 or 3 most of the time.

Of course over allocation of the pool size keeps WQ empty, but it also over allocates the system virtual memory, which may produce unnecessary paging or swapping.

This number of transaction server processes is tuned by the "set server_pool_size" in the configuration time and may be dynamically changed at run time.

The tuning of this parameter depends a number of factors. The most obvious factor is the expected workload of the server.

You need to consider the frequency with which transaction requests arrive, the required response time, and the type of application programs:

Programs that perform a lot of I/O requests are often dormant while they are running, while they wait for the responses to their requests. However, processing I/O requests can sometimes make considerable demands on the CPU. You need to consider whether you might need more transaction server processes for this type of service.

Programs that perform few I/O requests are usually constrained by the use they make of the central processor. With CPU-bound services, fewer transaction server processes usually work better, because the central processor switches between the running tasks, and this is an overhead.

The exact tuning of the server process pool may achieved monitoring the WQ when the region is alive and serving.

You may monitor the WQ with the command line utility "xcicsadm" or with the on-line transaction CESQ.

current wait queue length	the number of transaction currently waiting to be processed
maximum wait queue length	the maximum length of the queue detected
maximum wait queue time	the maximum time a transaction has been waiting in the queue
average wait queue time	the average time the transactions wait in queue
total transactions performed	the total number of transaction performed by the region

Additionally, XCICS/TS collects different information for each transaction executed, including:

These information may be programmatically analyzed or converted into a report by the "xreport" tool. For further reading on transaction statistics, please refer to the "Logging, Accounting & Journaling" section.

Background tasks normally do not run in the process shared pool, but they use a dedicated process created when the task starts and dismissed when the task end.

Tasks activate as response to a request coming through TCP/IP services may be run as standard background task in dedicated process, or in a process of the server process pool (use_engine parameter on the service definition). It depends on the service definition at configuration time.

Normally you may decide the execution method depending on the type of the request:

Short-running requests are requests where there is just one interaction between the client and the service; the client request arrives, the service runs, and a response is returned to the client. Requests from Web services clients are normally short-running. With short-running requests, you only need to consider whether or not the service itself is CPU-bound and handle it in the process pool, or I/O-bound and handle the service as a standard background task

Long-running client requests are requests where the same client can make repeated requests of a service and needs data to be preserved between invocations of the service. In this case the service must be handle a standard background task.

A SNA session is a process waiting for requests coming from the SNA network via APPC (i.e. DTP, DPL, etc.). This process receives and handle the request. When the request is satisfied, it becomes available for a new request.

The number of SNA sessions depends on the expected number of contemporary requests and on the their type, as described for TCP/IP services.

Memory buffers are the areas used by the XCICS/TS core process to exchange data with the transaction server processes.

Each time the main process needs to exchange data with a transaction server process, a free buffer of the requested size is used: if no suitable buffer is free, the communication is hold until one becomes available.

Therefore buffers size and number regulates the speed of the internal communication, and a larger number and size of buffers speeds up the internal communication.

This setting is very important especially for those application which make a large usage of "in-memory" temporary storage, transient data and background task activation.

Memory buffers may be tuned using the "add bufferset" directive in the configuration file