Each activity is described by a "MeanTimes" parameter in the first column (how many times it is executed, for one execution of the graph) and by its use of logical services which include logical processor instruction executions, file operations, and execution of other software modules. There is a column for each service, with the mean execution count. When this information is first obtained it is usually easier and more useful to define values for logical services rather than for hardware operations. Thus, a number of file read operations may be identified in the software and the expected number of these operations within one activity may be recorded. This leaves the task of identifying
to a later analysis, when more is known about the application, the operating system, the configuration, and the choice of hardware devices. For instance a file to be read may be on a disk attached to the processor, or accessed over a local network from a network file system like NFS. Both cases may have to be analyzed; the difference arises not in the description of the software but in other decisions. The case of file operations will be considered again, for example to deal with the size of each operation.
At the bottom of Figure 1. a set of totals is shown, which are the total request counts for service demands when the graph is executed once. The graph can be represented as a single aggregate activity, possibly for use within a graph written at a larger scale, and these are the parameters of that aggregate activity. In Figure 1. the graph is given the name g, and the aggregate activity has the same name.
Hardware device services are treated uniformly, defining an operation as a service. For processors we use the unit of the mega-instruction, or M-In, to obtain units of useful numeric size (since most operations take thousands or millions of instructions).
If, in Figure 1., we wanted to consider the file operations and the X-server operations Xwin.create and Xwin.inout as internal to the activities A to G we would have to substitute in their CPU service and disk operation request counts. Then we obtain the service request counts just for CPU and disk operations as shown in Figure 2. In this way all the logical service requests can be eliminated and the device request rate found; it is then only a small step to get a performance model as discussed in the previous chapter. This will be detailed below as Reduction R1.
Figure 1. Activity Graphs for a Module with Two Entries
Figure 2. Activity Graphs for a Module with Two Entries, with Software Service Demands Resolved into their Device Demands