Performance Parameters and Calculations in an Activity Graph

The performance parameters of an activity graph will be explained using the example shown in Figure 1. There are two activity graphs for a module m with two high level operations (or entries, as discussed later), called m.e1 and m.e2. The function of this module is not our concern, but it uses file operations and two X-windows functions listed here as Xwin.create, to create a new window, and Xwin.inout, to read and write text in the window.

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

  • how much is read and written
  • how many disk operations or network operations occur for each file operation
  • how long each disk operation takes

    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).

    Activity Graph Workload Parameters: Alternatives

    The analyst can determine what is considered to be internal to each activity and what is considered to be a service obtained by the activity from outside the software modelled by the graph. Making a service external allows it to be analyzed separately, and its parameters to be used in other models, so it is an aid in re-using performance information.

    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

    Real Time and Distributed Systems Group
    Last modified: Mon May 26 11:55:00 EDT 1997