Compaq ACMS for OpenVMS
Managing Applications


Previous Contents Index

14.6 Configuring the Application Execution Controller

The performance of the EXC process depends on the rate at which exchange steps are being executed and the complexity of the TDMS requests. Although there is a single EXC process for each application, the EXC process is normally able to handle all users of an application.

Insufficient working sets or an OpenVMS process priority that is too low for the EXC user name can significantly reduce the performance of the application. The EXC might require considerably more system resources than a typical interactive process because it controls many users at one time.

SPM can be used to monitor page faults in the EXC at the time of peak load periods. You can also use the DCL SHOW PROCESS/CONTINUOUS command, but restrict its usage to short periods of time because the command affects overall system performance.

Set the resource quotas for the EXC process on an individual basis using the ACMEXCPAR.COM command procedure (see Chapter 10). Each EXC process performs a specific function and requires specific resources to perform properly.

The application definitions created with ADU set up the user names under which the EXC controllers run. Use the OpenVMS Authorize Utility to change the working set size and priority for the user name of each EXC, if necessary. By using the OpenVMS Authorize Utility to change the priority and quotas associated with these user names, you can change the performance of the applications and the ACMS system. See the OpenVMS Authorize Utility documentation for more information. Compaq ACMS for OpenVMS ADU Reference Manual contains information on using ADU application definition clauses.

14.7 Configuring the Server Process

The performance of the server processes for an application depends mainly on how you define them in the application definition. The number of server processes available to an application can affect its performance. If too many servers are active, system resources are wasted. If too few servers are active, users might have to wait long periods of time before ACMS can allocate a server process to their application.

To determine whether or not there are enough server processes on the system for a particular application, use the ACMS /SHOW APPLICATION command. This command shows how many servers are active, how many users are waiting for server processes, and how many servers are busy. This information indicates whether or not there are enough servers on the system.

To change the operational characteristics of server processes, use the ADU and the OpenVMS Authorize Utility. The application definitions created with ADU include clauses that determine how many resources the application uses. For example, the MAXIMUM SERVER PROCESSES clause sets an upper limit for all server processes in an application.

An application definition also sets up the user names under which server processes and Application Execution Controllers run. By using the OpenVMS Authorize Utility to change the priority or quotas associated with these user names, you can change the performance of the applications and of the ACMS system. See the OpenVMS documentation on the Authorize Utility for more information. Compaq ACMS for OpenVMS ADU Reference Manual contains information on using ADU application definition clauses.

14.8 Tuning and Maintaining the Queued Task Facility

The performance of the QTI is affected by:

In addition, the performance of the QTI as well as the performance of processes which call the Queued Task Services, is affected by:

14.8.1 Configuring the QTI Process

The performance of the QTI is affected by how the process is configured. In particular, the performance is mainly affected by:

Specify the OpenVMS process priority with the ACMSGEN QTI_PRIORITY parameter. Depending on your application, you may want the QTI to run at the same priority as processes serving interactive users (for example, the CP), or you may want the QTI to run at a lower priority than interactive users (similiar to a batch process).

Specify the user name of the QTI with the ACMSGEN parameter QTI_USERNAME. This user name, and the quotas for this user name, are defined in the system user authorization file (SYSUAF.DAT) using the OpenVMS Authorize Utility. Ensure that the working set size of the QTI is sufficient so that it does not page excessively.

Use the ACMSPARAM.COM procedure (see Chapter 10) to define the user name of the QTI. This command procedure determines the quotas needed by the QTI depending on application-specific data which you provide. In addition, ACMSPARAM.COM will set the working set size to a reasonable first guess. Monitor the QTI during peak times to determine if the working set size requires adjusting.

14.8.2 QTI Task Execution Threads

When you start a task queue with the ACMS/START QUEUE operator command, you can specify the number of task execution threads using the /TASK_THREADS qualifier. By default, if you do not specify this qualifier, one task execution thread per queue is allocated to each started queue.

The number of task execution threads controls how many task invocations can be outstanding at any one time. With multiple task execution threads, the dequeuing of queued task elements and the invocation of queued tasks occur concurrently. Therefore, when you increase the number of threads, you increase the throughput. As you increase the number of threads, the QTI uses more system resources such as CPU and disk IOs. Therefore, balance the usage of these resources as needed among other components of your application.

If you have multiple queues being processed by the QTI, then you can favor one queue over other queues by assigning it more task execution threads.

The rate at which the QTI processes elements of one queue relative to another queue is a function of the number of task threads per queue and the time it takes to execute the queued tasks. Each QTI task thread does its processing loops (dequeue element, invoke queued task) independently of any other thread. Therefore, you have to consider the time delay of the tasks which are being invoked when trying to calculate the rate at which elements are processed in one queue relative to another queue.

For example, assume you have started the task queues MY_QUE and YOUR_QUE, and MY_QUE is assigned one task execution thread and YOUR_QUE is assigned two task threads. If the execution time of the tasks in the two queues is the same, there will be twice as many queued task elements processed in YOUR_QUE than in MY_QUE. If, however, the execution time of the tasks in MY_QUE is twice as long as those in YOUR_QUE, then there will be four times as many queued task elements processed in YOUR_QUE than in MY_QUE.

Although it is possible to specify up to 255 task execution threads per queue, normally you specify a relatively small number. After a certain point, increasing the number of task execution threads does not increase throughput. Each task execution thread consumes memory and requires higher process quotas. Therefore, increasing the number of task execution threads beyond a certain point only wastes these resources. In practice, specifying 1 to 10 task execution threads is sufficient to meet your needs.

14.8.3 Tuning Task Queue Files

The ACMS Queued Task Facility is layered on RMS. Specifically, each task queue repository is an RMS indexed file. Therefore, tune task files just as you would any RMS indexed file.

The steps you use to modify RMS tuning variables associated with the task queue file are:

  1. Generate a File Definition Language (.FDL) file for an existing task queue repository by using the DCL ANALYZE/RMS_FILE/FDL command.
    For example, assume you have created a task queue using the ACMS Queue Manager and the file specification associated with the task queue is SYS$SYSTEM:PAYROLL_QUEUE.DAT. Generate an .FDL file by issuing the following command:


    $ ANALYZE/RMS_FILE/FDL SYS$SYSTEM:PAYROLL_QUEUE.DAT
    

  2. Modify the RMS tuning variables in the .FDL file as needed by using the EDIT/FDL Utility.
    For example, using the .FDL file generated from the example in the previous step, invoke the EDIT/FDL Utility with:


    $ EDIT/FDL PAYROLL_QUEUE.FDL
    

    From within the EDIT/FDL Utility, modify the RMS tuning variables as needed. ACMS uses the RMS defaults for all the tuning variables. Specific tuning variables which you might want to modify depending on your application include:


    For more information on tuning RMS indexed files, see the OpenVMS documentation on RMS.
  3. Convert the queued task repository file by using the Convert Utility on the .FDL file from the previous step:


    $ CONVERT/FDL=PAYROLL_QUEUE SYS$SYSTEM:PAYROLL_QUEUE.DAT -
    _$ SYS$SYSTEM:PAYROLL_QUEUE.DAT 
    

    The Convert Utility generates a new queued task repository file having a higher version number than the original queued task repository file. The Queued Task Facility depends on the original file version. Therefore, you must delete the original file and rename the new converted file to have the old version number. For example:


    $ PURGE SYS$SYSTEM:PAYROLL_QUEUE.DAT
    $ RENAME SYS$SYSTEM:PAYROLL_QUEUE.DAT; ;1     
    

    For more information on the ANALYZE/RMS_FILE Utility, the EDIT/FDL Utility, and the Convert Utility, see Guide to OpenVMS File Applications.

14.8.4 Maintaining Task Queue Files

The ACMS Queued Task Facility is layered on RMS indexed files. In a running application, elements are enqueued to a task queue, and at some later point in time they are dequeued. These operations translate to write and delete operations on the RMS indexed file. RMS retains buckets in indexed files even if all the records in the bucket have been deleted.

Over time, these empty buckets can accumulate and needlessly waste disk space. In addition, these empty buckets can cause a performance degradation of the QTI process if your application uses multiple priority levels of queued task elements and the highest priority in the task queue changes frequently.

Use the Convert or Convert/Reclaim Utilities on the task queue repository files to reclaim these unused buckets. If you use the Convert Utility, you also need to rename the new task queue repository file to have the original version number. For more information on the Convert and Convert/Reclaim Utilities, see Guide to OpenVMS File Applications.

Perform this file maintenance on a regular basis. Because the Convert Utilities require exclusive access to the file, you need to perform this maintenance during a time when your application needs little access to the queue file.

14.9 Tuning Checklist

Use the following checklist to establish a sound management routine that helps you maintain good performance on your ACMS system.

  1. As system manager, routinely:
  2. Use tuning as a last resort to solve a performance problem:
  3. If you find that you must tune your system by adjusting system parameters:
  4. After you make adjustments:


Chapter 15
Using DECtrace with ACMS Applications

DECtrace is a product that collects and reports on event-based data gathered from any combination of OpenVMS layered products and application programs. If DECtrace is installed on your system, you can use it to collect detailed information about applications that use the ACMS software.

15.1 Overview of DECtrace

DECtrace refers to layered products and applications as facilities. DECtrace allows layered products, such as ACMS and Rdb, to define events. ACMS has many predefined events that occur at run time. An event can have a start and an end (duration event), or it can simply occur (point event).

Because DECtrace is event-based, it provides you with several advantages:

DECtrace records several different pieces of information, called items, for each event. Items can be:

Section 15.3.1 contains descriptions of ACMS events and items.

To use the DECtrace commands, preface them with the keyword COLLECT. For example:


$ COLLECT SHOW VERSION
DECtrace Version V1.2-0
$ 

For better user interface performance, you can enter the DECtrace command environment by entering the COLLECT command with no arguments at the DCL prompt. DECtrace prompts you for commands until you return to DCL command level by entering the EXIT command. This eliminates binding to the history and administration databases for each command. For example:


$ COLLECT  
DECtrace> SHOW VERSION
DECtrace Version V1.2-0
DECtrace> EXIT
$ 

15.2 Improving Application Management with DECtrace

DECtrace records information about specific events or items within the events in an ACMS application. To record this information, you simply activate the collection of the desired event data with a DECtrace command. See DECtrace documentation for more information.

You can use DECtrace for a variety of application or system management functions:

15.3 Collecting Event Data for ACMS

To collect event data with DECtrace, you must first create a facility selection and then schedule data collection using that selection. This section describes how to create a facility selection and schedule data collection for ACMS applications.

15.3.1 Describing ACMS Events and Items

Each time a predefined event occurs in an ACMS application, and if a collection is scheduled, DECtrace records the event items in a data file. In your facility selection, you can decide to collect either all of the events and items available or a predefined subset of these events and items (called a collection class---see Section 15.4.2). You can use this collected data to identify information for a variety of uses such as how frequently an event occurs, what order events occur in, or how long an event takes to complete.

Note

DECtrace collects all occurrences of each event in your chosen collection class. You cannot choose individual events to record. However, you can create reports based on specified events by using the REPORT command. See Section 15.5 for information on DECtrace reporting.

Note that if you use an agent other than the one provided by ACMS, the agent must be instrumented with DECtrace service routine calls in order to collect the ACMS event data associated with that agent. The following events must be instrumented in the customer-written agent process if you want them to be collected: REMOTE_REQUEST, FORMS_ENABLE, and FORMS_REQUEST.

Each event has various items associated with it. These items include a set of standard DECtrace resource utilization items, a set of facility-specific items and a set of cross facility items. Table 15-1 lists the standard resource utilization items. Table 15-2 lists the ACMS-specific data items. Table 15-3 lists the cross facility items.

15.3.1.1 ACMS Events

This section describes the events that can occur in your ACMS application.

TASK

A task within the application. This event is written to the data collection file by the EXC. The start event is recorded when the start call is received from the CP. The end event call is recorded immediately preceding the return call to the CP.

ACMS can log chained tasks as separate TASK events. You can use the PARENT_TASK and STEP_NAME items to identify tasks called by other tasks. (If a task is not called by another task, ACMS leaves these two items blank.)

EXCHANGE_STEP

An exchange step within a task. This event is written to the data collection file by the EXC. The start event is recorded at the beginning of step processing. The end event is recorded at the end of step processing.

PROCESSING_STEP

Processing step within a task. This event is written to the data collection file by the EXC when a processing step:

The start event is recorded at the beginning of step processing. The end event is recorded at the end of step processing.

REMOTE_REQUEST

Remote request terminal I/O executed by the agent process. This event is written to the data collection file by the ACMS Remote Request Server (RR). The start event is recorded whenever a TDMS request is received. The end event is recorded when the request completes.

PROCEDURE_CALL

User's server procedure in a processing step. This event is written to the data collection file by the SP. The event reflects the time and resources used by the customer-written procedure.

TASK_WAIT

Task waiting for server processes. This event is written to the data collection file by the EXC. The start event is recorded when no server is available to process the request. The end event is recorded when a server becomes available. This event is part of the PROCESSING_STEP event.

TRANSACTION

An ACMS transaction. This event is written to the data collection file by the SP or EXC. This event is started when ACMS starts a transaction and is ended upon completion of the transaction.

FORMS_ENABLE

A DECforms enable performed by the agent process. This event is written to the data collection file by the ACMS DECforms Server (VFS). The first time a user references a form, it must be enabled.

FORMS_REQUEST

A DECforms request executed by the agent process. This event is written to the data collection file by the ACMS DECforms Server (VFS). This event is recorded whenever ACMS executes a DECforms request (SEND, RECEIVE, TRANSCEIVE).

SUB_RESPONSE

The SUB_RESPONSE event is a duration event that records the time that ACMS takes to respond to a DECforms, TDMS, or stream I/O request from the submitter node, excluding the overhead associated with the forms product. This event is written to the data collection file by one of the following:

ACMS logs the start of the event whenever a DECforms, TDMS, or stream I/O forms request is completed, and at the start of each task. ACMS logs the end of the event at the start of the next forms request within the same task or, if no forms request follows, when the task is completed. Figure 15-1 shows the point at which ACMS measures the SUB_RESPONSE event: the task start, during the task, and the task end.

Figure 15-1 Measuring the SUB_RESPONSE Event


The following rules apply to the SUB_RESPONSE event for tasks with no I/O operations, tasks calling other tasks, or chained tasks:

The response time measured by the SUB_RESPONSE event includes the time required for network communications with the application node, and the time required for the node to perform application processing. These values are collected in the NETWORK_TIME and PROCESSING_TIME items, respectively. DECtrace records the total elapsed time for this event, and all events, by default.

However, if a SUB_RESPONSE event occurs between the final form request and the end of a task, the application node cannot send the processing time back to the submitter node. In fact, neither the NETWORK_TIME nor the PROCESSING_TIME items are available, so DECtrace collects a value of zero for both items.

Note

When the node name is not specified in ACMSGEN, the SUB_RESPONSE event does not log the APPL_NODE item in most cases. However, if you use TDMS or stream I/O, the SUB_RESPONSE event logs the APPL_NODE item for those operations.

APL_RESPONSE

The APL_RESPONSE event is a duration event that records the time the application node takes to respond to an exchange step, excluding the network and forms product overhead associated with the exchange step. This event is written to the data collection file by the EXC. Having a separate response time event on the back-end node allows you to make adjustments on this node and observe the effects isolated on one node.

ACMS logs the start of the event when an exchange step is completed, or, if no exchange step has executed yet within this task, ACMS logs the start of the event when the Application Execution Controller (EXC) starts the task. ACMS logs the end of the event when the next exchange step within the same task starts, or, if no exchange steps follow, when the task is completed. Figure 15-2 shows when ACMS logs the APL_RESPONSE event.

Figure 15-2 Measuring the APL_RESPONSE Event


The rules that apply to the SUB_RESPONSE event regarding tasks with no I/O operations, tasks that call other tasks, or chained tasks also apply to the APL_RESPONSE event.

COMPRESSED_MSG

The COMPRESSED_MSG event shows the effect of data compression on network messages sent between the application and submitter nodes. This event is written to the data collection file by the Stream Services (STRM) and Server Services (SER). The COMPRESSED_MSG event is a point event. The purpose of a point event is to mark the occurrence of an operation, rather than to measure the duration of the event.


Previous Next Contents Index