When you are dealing with limit conditions, you may find it helpful to
check the various points where performance constraints can exist in a system.
These points are summarized below under hardware and software constraints.
- Processor cycles. It is not uncommon for transactions
to execute more than one million instructions. To execute these instructions,
they must contend with other tasks and jobs in the system. At different times,
these tasks must wait for such activities as file I/O. Transactions give
up their use of the processor at these points and must contend for use of
the processor again when the activity has completed. Dispatching priorities
affect which transactions or jobs get use of the processor, and batch or other
online systems may affect response time through receiving preferential access
to the processor. Batch programs accessing online databases also tie up those
databases for longer periods of time if their dispatching priority is low.
At higher usages, the wait time for access to the processor can be significant.
- Real storage (working set). Just as transactions
must contend for the processor, they also must be given a certain amount of
real storage. A real storage shortage can be particularly significant in CICS® performance because a normal page fault to acquire real storage results
in synchronous I/O. The basic design of CICS is asynchronous, which means that CICS processes requests from multiple tasks concurrently to make maximum
use of the processor. Most paging I/O is synchronous and causes the MVS™ task that CICS is using to wait, and that part of CICS cannot do any further processing until
the page operation completes. Most, but not all, of CICS processing
uses a single MVS task (called ‘QUASI’ in the dispatcher statistics).
- Database-associated hardware (I/O) contention.
When data is being accessed to provide information that is required in a transaction,
an I/O operation passes through the processor, the processor channel, a disk
control unit, the head of string on a string of disks, and the actual disk
device where the data resides. If any of these devices are overused, the
time taken to access the data can increase significantly. This overuse can
be the result of activity on one data set, or on a combination of active data
sets. Error rates also affect the usage and performance of the device. In
shared DASD environments, contention between processors also affects performance.
This, in turn, increases the time that the transaction ties up real and virtual
storage and other resources.
The use of large amounts of central and expanded
storage by using very large data buffers, and by keeping programs in storage,
can significantly reduce DB I/O contention and somewhat reduce processor utilization
while delivering significant internal response time benefits.
- Network-associated hardware contention. The input
and output messages of a transaction must pass from the terminal to a control
unit, a communications link, a network controller, a processor channel, and
finally the processor. Just as overuse of devices to access data can affect
response time, so excessive use of network resources can cause performance
degradation. Error rates affect performance as well. In some cases, the
delivery of the output message is a prerequisite to freeing the processor
resources that are accessed, and contention can cause these resources to be
tied up for longer periods.
- Database design. A data set or database needs
to be designed to the needs of the application it is supporting. Such factors
as the pattern of access to the data set (especially whether it is random
or sequential), access methods chosen, and the frequency of access determine
the best database design. Such data set characteristics as physical record
size, blocking factors, the use of alternate or secondary indexes, the hierarchical
or relational structure of database segments, database organization (HDAM,
HIDAM, and so on), and pointer arrangements are all factors in database performance.
The length of time between data set reorganizations can also affect performance.
The efficiency of accesses decreases as the data set becomes more and more
fragmented. This fragmentation can be kept to the minimum by reducing the
length of time between data set reorganizations.
- Network design. This item can often be a major factor in
response time because the network links are much slower than most components
of an online system. Processor operations are measured in nanoseconds, line
speeds in seconds. Screen design can also have a significant effect on overall
response time. A 1200-byte message takes one second to be transmitted on
a relatively high-speed 9600 bits-per-second link. If 600 bytes of the message
are not needed, half a second of response time is wasted. Besides screen
design and size, such factors as how many terminals are on a line, the protocols
used (SNA, bisynchronous), and full-or half-duplex capabilities can affect
performance.
- Use of specific software interfaces or serial functions. The operating system, terminal access method, database manager, data
set access method, and CICS must all communicate in the processing of a transaction.
Only a given level of concurrent processing can occur at these points, and
this can also cause a performance constraint. Examples of this
include the VTAM® receive any pool (RAPOOL), VSAM data set access (strings), CICS temporary storage, CICS transient data, and CICS intercommunication sessions. Each of these can have
a single or multiserver queueing effect on a transaction’s response time,
and can tie up other resources by slowing task throughput.
One useful technique for isolating a performance constraint in a CICS system with VTAM is to use the IBMTEST command issued
from a user’s terminal. This terminal must not be in session with CICS, but must be connected to VTAM.
You enter at a VTAM terminal:
IBMTEST (n)(,data)
where n is the number of times you want the data echoed,
and data may consist of any character string. If you enter no data,
the alphabet and the numbers zero through nine are returned to the terminal.
This command is responded to by VTAM.
IBMTEST is an echo test designed to give the user a rough idea of the VTAM component of terminal response time. If the response time is fast in
a slow-response system, the constraint is not likely to be any component from VTAM onward. If this response is slow, VTAM or the network may be the reason. This
sort of deductive process in general can be useful in isolating constraints.
To avoid going into session with CICS, you may have to remove APPLID= from
the LU statement or CONNECT=AUTO from the TERMINAL definition.
[[ Contents Previous Page | Next Page Index ]]