A full-load measurement highlights latent problems in the system. It is important that full-load measurement lives up to its name, that is, you should make the measurement when, from production experience, the peak load is reached. Many installations have a peak load for about one hour in the morning and again in the afternoon. CICS® statistics and various performance tools can provide valuable information for full-load measurement. In addition to the overall results of these tools, it may be useful to have the CICS auxiliary trace or RMF™ active for about one minute.
CICS auxiliary trace can be used to find situations that occur under full load. For example, all ENQUEUEs that cannot immediately be honored in application programs result in a suspension of the issuing task. If this frequently happens, attempts to control the system by using the CEMT master transaction, are not effective.
Trace is a very heavy overhead. Use trace selectivity options to minimize this overhead.
It is advisable to do the RMF measurement without any batch activity. (See Resource measurement facility (RMF) for a detailed description of this tool.)
For full-load measurement, the system activity report and the DASD activity report are important.
The most important values for full-load measurement are:
You should expect stagnant throughput and sharply climbing response times as the processor load approaches 100%.
It is difficult to forecast the system paging rate that can be achieved without serious detriment to performance, because too many factors interact. You should observe the reported paging rates; note that short-duration severe paging leads to a rapid increase in response times.
In addition to taking note of the count of start I/O operations and their average length, you should also find out whether the system is waiting on one device only. With disks, for example, it can happen that several frequently accessed data sets are on one disk and the accesses interfere with each other. In each case, you should investigate whether a system wait on a particular unit could not be minimized by reorganizing the data sets.
The RMF DASD activity report includes the following information:
Use IOQ(DASD) option in RMF monitor 1 to show DASD control unit contention.
After checking the relationship of accesses with and without arm movement, for example, you may want to move to separate disks those data sets that are periodically very frequently accessed.
You might wish to consider using a comparison chart to measure key aspects of your system’s performance before and after tuning changes have been made. A suggested chart is as follows:
Observations to make | Run A | Run B | Run C | Run D | |
---|---|---|---|---|---|
DL/I transactions: Number | |||||
DL/I transactions: Response | |||||
VSAM transactions: Number | |||||
VSAM transactions: Response | |||||
Response times: DL/I | |||||
Response times: VSAM | |||||
Most heavily used transaction: Number | |||||
Most heavily used transaction: Response | |||||
Average-use transaction: Number | |||||
Average-use transaction: Response | |||||
Paging rate: System | |||||
Paging rate: CICS | |||||
DSA virtual storage: Maximum | |||||
DSA virtual storage: Average | |||||
Tasks: Peak | |||||
Tasks: At MXT | |||||
Most heavily used DASD: Response | |||||
Most heavily used DASD: Utilization | |||||
Average-use DASD: Response | |||||
Average-use DASD: Utilization | |||||
CPU utilization |
|
The use of this type of comparison chart requires the use of TPNS, RMF, and CICS interval statistics running together for about 20 minutes, at a peak time for your system. It also requires you to identify the following:
To complete the comparison chart for each CICS run before and after a tuning change, you can obtain the figures from the following sources:
This chart is most useful when comparing before-and-after changes in performance while you are tuning your CICS system.