Establishing performance objectives in a DBCTL environment

Inherent in the design of your online DBCTL/CCTL system are your performance objectives. Establishing performance objectives is a major task requiring data gathering for the DBCTL/CCTL workload as a whole. After defining the workload and estimating the resources required, you must reconcile the desired response with the response you consider to be attainable. Monitor the performance of the system to determine if these objectives are being met.

Base performance objectives on:

• Desired, acceptable, and maximum response time
• Average and maximum resource demands (or workload) per transaction
• Predicted and actual transaction volumes

Establishing your performance objectives is an iterative process involving the following activities:

• Defining CCTL user-oriented performance objectives and priorities

  These derive from the way a CCTL end user perceives the service provided by the system. These objectives state expectations of response time as seen by the end user at the terminal.

  When response time objectives are established, they should not only reflect the time-in-system (the elapsed time from entry of a last input message segment to the first response segment), but also the expected amount of IMS, CCTL, and application program processing. You should consider whether to define your criteria in terms of the average, the 90th percentile, or even worst-case response time. Your choice depends on your installation's audit controls and the nature of the specific transactions.

• Determining how performance against these objectives is measured and reported to users

  You can combine UOR data with CCTL transaction data for a complete transaction profile, but keep the following things in mind:

  • If a CCTL allows only one UOR per transaction, this one-to-one ratio makes it easy to combine the monitoring data. It is also easier to track, because a CCTL can put a transaction-ID into a SCHED request. DBCTL puts this ID in monitor log records, and it appears in monitor reports.
  • If a CCTL allows for multiple UORs within a single transaction, the total UOR data can be obtained by adding the data from each of the UORs.

  Besides data from the IMS Monitor, UOR data is also provided to a CCTL upon the completion of a request terminates the UOR. This data can be used in either of the cases above. A CCTL can also perform real-time analysis of UOR statistics related to its transactions.

  The same UOR data is also part of the IMS system log, which records the status and end of a UOR.

• Understanding and documenting the current workload

  This requires breaking down the total work into categories and, for each category, developing a workload profile (generally estimates) that include:

  • Definition of the transaction category (for example, transaction type or group of transactions). Two characteristics of the category are:
    • The transaction profile. Most transactions perform a single function and have an identifiable workload profile. Later in the process, transaction types with common profiles can be amalgamated for convenience.
    • The transaction volume. In situations where the workload to be documented is already operational, a summary of transaction volumes can be obtained. In other cases, volumes are estimated.
  • Relative priority of category, including periods during which priority changes
  • Resource requirements of the work:
    • Physical resources managed by the operating system (real storage, DASD I/O, terminal I/O)
    • IMS logical resources managed by the subsystem, such as control blocks, latches, buffers, and number of database resource adapter (DRA) threads
    • CCTL resources required

  To obtain a base profile of transaction resource demands, you can start DBCTL/CCTL on a dedicated machine and execute a few transactions to accomplish initialization and buffer pool usage. Then start the IMS Monitor and measure a sample of transaction execution.

  You can use the base transaction profile to examine the transaction workload to see if there is any way to reduce it. Such design changes result in the greatest impact, occurring before system-wide contention. You can also compare the base profile against the transaction profile in the production environment.

• Translating the resource requirements and volume information obtained into system-oriented objectives for each work category

  This includes statements about the transaction rates to be supported (including any peak periods) and the internal response-time profiles to be achieved.

• Confirming that the system-oriented objectives are reasonable

  After initializing the system and monitoring its operation, you need to find out if the objectives are reasonable (given the hardware available), based upon the measurements of the workload. If the measurements differ greatly from the estimates used, you must revise the workload documentation and system-oriented objectives accordingly, or tune the system.