Table of contents for Performance Model Example

1. Performance Model Example
2. Example: Function definition
3. Example: Defining users and locations
4. Example: Usage Definition
5. Example: User demand estimation

Having defined the key system functions and the user population it is now necessary to define how the users place a functional demand on the system. (The online version of this article has more detail again.) The first part of this definition is to lay out how the usage of the system varies over time. Thus the relative usage of the system needs to be defined. The initial definitions are on an intra-hour, hourly, daily, weekly and monthly basis. These figures effectively have no units and simply provide a relative level of usage. Thus any metrics that are available to allow calibration of this data can be used. As an example, estimated percentage utilisation of the system for the time period could be provided. Alternatively, there may be historical data available from a production system.

In the majority of the usage profile sheets the data entry allows a default profile to be entered at the top of the sheet. This can then be varied for individual user sections where they vary significantly. Thus, for example, most of the user sections have similar behaviour this would be used for the default profile. The significant variations from this behaviour would then be entered individually for the separate user section rows that this was required for.

There is a further possibility of varying the use of different functions within a time period, in our example there is likely to be a bias in the number of payments created and approved around the cut off times for making those payments.

The facility extends to a monthly and weekly specification:

The “Intrahour” entry is different. In this case a simple ratio is provided between the peak activity within an hour and the average activity for the hour. This value represents the relative activity instability of the system under consideration, with a higher value representing a system with very unstable usage within any given hour.

The “Annual” data entry is different again. In this case a reference year for the modelling is defined, and the modelling extends for ten years including this starting year. The number of working days per year is also entered in this sheet, and then the size of the user population for each user segment in each year. Thus, the expected population growth for each of the user segments may be defined over a ten year period.

Note:In this exmple it is worth noting that the “User population” count for the email and standing order systems has been set to the expected number of items per day. This is a useful modelling mechanism in the case of batch oriented processes.

Lastly in the definition of the system demand by the system’s behaviour types (“Behaviour type function usage”). In this case the average use of each function by each user per day broken down by behaviour type. Using all of this information it is possible to calculate a detailed profile of the expected system demand. This information and its usage will be examined next.