Model 204 Tracking Transactions for Performance: Part 1
By James Damon
Over the past several months, Iíve written several articles about collecting performance statistics, automating the collection of those statistics, and simulating multi-user environments as a way to generate performance statistics in a controlled environment. What I havenít discussed until now is which of the statistics are the most helpful in analyzing performance and what do they say about performance in your environment.
Youíve gone to the trouble of collecting this data because youíve wondered or youíve been asked by others to answer some very basic questions about your environment.
These are the kinds of questions managers, directors and capacity planners often ask. The answers are available from Model 204.
Identifying a Unit of Work
The first step in measuring performance is to determine what constitutes a unit of work in your environment. Once you have a count of the number of units of work processed, you can use other statistics to compute costs and response times.
As seen by the end-user in a Model 204, full-screen APSY environment, a unit of work or transaction is the work that occurs between one screen display and the next. Regardless of whether the unit of work is update or read-only, it is counted as a transaction.
The work that occurs between two READ SCREEN statements might look something like the following in User Language pseudo code:
BEGIN Define screens and variables READ SCREEN ABC - Collect data from user START TRANSACTION - User presses ENTER or PFKEY |---- Find records | Extract data | Perform calculations | Cross reference to other files and do FINDs | Continue in next APSY procedure | END | | BEGIN | CHANGE, STORE, and so on start update transaction | COMMIT end update transaction |---- READ SCREEN XYZ display next screen END TRANSACTION Continue END
Define screens and variables READ SCREEN ABC - Collect data from user
Understanding the SCREENS statistic
Between the two screen displays a certain amount of processing occurs. CPU is consumed to get the user from START to END. Some database I/O and CCATEMP I/O occurs. It is possible that the end-user is swapped to CCASERVR between START and END statements. Also, record and resource locking might introduce some delays, as will device and channel contention and contention for CPU.
This between-screens type of transaction is counted in the SCREENS statistic. Whenever a User Language READ SCREEN statement is evaluated, the SCREENS statistic is incremented by one. If the Online consists primarily of APSY or even non-APSY, full-screen applications then the SCREENS statistic provides a direct count of the number of those kinds of transactions processed. This statistic is maintained separately for each user, each application, and as a cumulative statistic for the entire run.
The SCREENS statistic is available at the end of the run in CCAAUDIT as part of system-final statistics. You can also view it at any time during the run by issuing a MONITOR STAT command. The SCREENS statistic, when combined with several others, can give an extremely accurate picture of performance for the run as a whole or for the run up to any point in time when the MONITOR STAT command is used.
To see how you might use this at your site, consider the following statistics collected recently from an end-of-day CCAAUDIT at a large customer site:
Evaluating a set of statistics
With this small subset of end-of-run statistics, you get a clear picture of workload and performance in this environment.
You know from the data available that:
CNCT = 83688 seconds
SCREENS = 2470563
For the sake of this discussion, assume that User Language, full-screen transactions are the only type of transaction processed in this system. Then you can also draw the following conclusions:
(SCREENS/CNCT)
(CPU/SCREENS)
(DKRD+DKWR) / SCREENS
(SVRD+SVWR) / SCREENS
Establishing Benchmarks
Once you have a raw or derived number, you have a transaction count that you can use as a benchmark for measuring subsequent changes in performance. These performance changes might result from changes in system or CCAIN parameters or from application or file changes. The only way to know if those changes had an effect is to measure transaction performance in the new environment using a benchmark transaction count.
Assessing Other Units of Work
In reality, other types of transactions are processed in an Online while the screen-to-screen transactions are occurring. For example, there might be BATCH2 threads, Horizon threads, background tasks doing file backups, and other types of processes that do not employ the READ SCREEN statement. Those processes all consume resources. How then, do we define a transaction in those instances? This is where measuring performance becomes more challenging.
There is no clear-cut definition of a transaction for these units of work. If you simply ignore them, then you are averaging the resources they consumeóCPU, database I/O, server swapping and othersóacross the quantifiable APSY, full-screen transactions, which gives a less than accurate picture of transaction performance.
Coming attractions
It is difficult to determine which statistic to consider when attempting to factor these other units of work into the transaction metric. Should we consider FINDS, RECADD, RECDEL, RECDS, or other statistics as other types of transactions? If so, do we end up double counting certain kinds of transactions?
Weíll explore those issues and others in the next CCAPRINT.
By Tym Stegner
For the past two months, I've discussed dataset maintenance and dataset damage detection. By now, I expect several sites are looking over their existing processes for dataset maintenance, or are considering creating processes to do so.
One thing that would help is the ability to locate all the System 1032 datasets and related files on the system. As System 1032 isn't locked in to the formal DBA management of a user's datasets, after a few years it may be difficult to locate all the System 1032-created files on your system.
While you are very familiar with DMB, DMC, DMD, and DMS files (database, command, definition, and dataset files, respectively), System 1032 actually creates a number of files, ranging from DMB, a database catalog, through DMW, a System 1032/REQuest description file. The full list of System 1032-related file types, all with an extension that begins with DM, can be found on pages 9-10 of the System 1032 Programmer's Reference Manual, Module II.
Although you can easily locate DMS and DMB files on your system, it is more difficult to locate them across more than one disk. Furthermore, if you have many disks, it is a nuisance to list all the disks you want to consider and to know which disks should be considered. You need the DM_SCAN utility.
Introducing DM_SCAN
Executing the DM_SCAN utility with its default settings locates and lists (to a file) every System 1032-created file, except .LIS and .RPT files, on all disks present in your cluster. Other capabilities include automatic dataset damage detection, and creation of DMC files to open located datasets.
Executing the DM_SCAN utility without any parameters invokes its help text. The help text begins with a list of System 1032 file extensions with explanations. The following syntax is for the DM_SCAN utility:
System 1032 file extensions:
.DMB - Database container
.DMF - ASCII image of Form
.DMJ - Dataset journaling
.DMP - Shared IC storage*
.DMS - Dataset container
.DMU - Extra damage history
.DMW - Request report
*May not be in use on your system
DM_SCAN command syntax:
@DM_SCAN {ALL|DMS|[{-L...|-X...}]}
[{ALL|list}] -
[{action(s)|ALL}] -
[options]
P1 ALL
P1 DMS
P1 -L...
P1 -X...
P2 ALL
P2 list
Options
= Per action settings
The DM_SCAN utility takes three primary parameters and four optional parameters. The P1 parameter controls which of the System 1032 file extensions to locate. Parameter P1 is the only required parameter. The other parameters have a default value, if nothing is specified.
Note: The DM_SCAN utility uses the F$SEARCH DCL lexical function to scan for "*.DM%*", filter the results, and perform the required actions on the qualifying files. The number of files present on your system determines how long the scan takes.
Extension Parameter P1
The P1 parameter value, ALL, directs the DM_SCAN utility to locate all System 1032-related files. The DMS parameter value limits the scan to only dataset files. The -L or -X option of P1 lets you manipulate the default extension list.
Note: -L and -X are mutually exclusive; you cannot both include and exclude file extensions. Extensions listed in -L or -X are validated against the default extension list.
For example, to locate the basic System 1032 catalog files, you would execute DM_SCAN as follows. The period separators are required.
$ @DM_SCAN -L.DMB.DML.DMS ALL ALL
Disk Parameter P2
The P2 parameter controls which disks are searched for the file extensions listed in the parameter P1.
By default, and if the ALL parameter value is specified, all file-oriented disks in the current cluster are searched. You can limit the file scan to a particular disk or to a list of disks by specifying the disk name(s) as a comma-delimited list.
For example, to locate System 1032 files on only a disk named CHECKOUT, issue the following command:
$ @DM_SCAN ALL DISK$CHECKOUT: 1
Action Parameter P3
In addition to the basic listing capability [action=1], the DM_SCAN utility can also perform two other tasks:
You can also specify ALL to indicate all possible tasks.
The action parameter values are read as a bitmask, which enables one or more of the actions to be performed simultaneously by adding the action values together. For example, to create a listing of dataset files on the TESTING1 disk, and also checking damage on those datasets, you would use the following command:
$ @DM_SCAN DMS DISK$TESTING1: 3
The listing action is value 1; the damage check is value 2; the total is 1 + 2 = 3.
Action Options Parameter P4+
The DM_SCAN utility has several outputs for its functionality. These values have defaults, which can be overridden.
You can specify the options in any order, beginning at P4.
Availability
The DM_SCAN utility is available As-Is via anonymous FTP from FOX.CCA-INT.COM, subdirectory [.CCAPRINT] to help you locate the datasets and other System 1032-related files your end-users created.
Copyright © 2008 Computer Corporation of America. All right reserved. Published in the United States of America.
Contact CCA Webmaster Copyright 2008
