| Previous | Contents | Index |
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:
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:
$ ANALYZE/RMS_FILE/FDL SYS$SYSTEM:PAYROLL_QUEUE.DAT |
$ EDIT/FDL PAYROLL_QUEUE.FDL |
$ CONVERT/FDL=PAYROLL_QUEUE SYS$SYSTEM:PAYROLL_QUEUE.DAT - _$ SYS$SYSTEM:PAYROLL_QUEUE.DAT |
$ PURGE SYS$SYSTEM:PAYROLL_QUEUE.DAT $ RENAME SYS$SYSTEM:PAYROLL_QUEUE.DAT; ;1 |
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.
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 $ |
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:
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.
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.
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.)
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 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 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.
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 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.
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.
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.
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).
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.
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. |
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.
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 |