Statistics collection and monitoring with remapped activities

Statistics affected by remapped activities

As one exception to the rule, the activity interarrival time, estimated cost, and queue time are all associated with the subclass in which an activity starts running, rather than with the subclass in which the activity finishes running. Because a remapped activity affects the statistics collection of both subclasses, a different number of activities can be counted in an interarrival time, an estimated cost, or a queue-time histogram than in a lifetime or execution-time histogram.

For example, consider an activity that starts running in service subclass A and later is remapped to service subclass B, in which it finishes running. The estimated cost of this activity is associated with service subclass A, but its lifetime is associated with service subclass B. As a result, for subclass A, the estimated cost histogram has one more element counted in it than the lifetime histogram has counted in it, and for service subclass B, the lifetime histogram has one more element counted in it than the estimated cost histogram has counted in it.

As a second exception to the rule, the monitor element concurrent_act_top can be updated in and attributed to any subclass that an activity passes through. In addition to being incremented when an activity begins and decremented when an activity ends, the monitor element is incremented when an activity is mapped to the subclass and is decremented when an activity is mapped out of the subclass (mapped to a different subclass).

Statistics about activity remapping

You can use two monitor elements to count the number of activities entering or leaving a service subclass because of a remapping action: act_remapped_in and act_remapped_out. The act_remapped_in and act_remapped_out monitor elements count the number of activities for any given subclass at any partition that were mapped into or out of the subclass since the last reset. You can use these monitor elements to validate that the remapping of activities between service subclasses is occurring as expected.

To determine the source and destination service subclasses targeted by a remapping action, you can refer to the threshold violation event monitor record, which includes a destination service class ID (destination_service_class_id). You can also determine the source service class by using the threshold violation record.

Monitoring with activity remapping

Remapping activities to different subclasses affects how you monitor these activities. To ensure that all statistics are collected for an activity that starts in one service class and finishes in another because of remapping, turn on aggregate activity data collection for both the service subclass in which the activity starts running and the service subclass in which the activity finishes running when you create or alter the service classes. If you turn on aggregate activity data collection for only the service subclass in which the activity started, the activity contributes only to queue time statistics and, in the case of extended statistics, to the estimated cost and interarrival time statistics. If you turn on aggregate activity data collection for only the service subclass in which the activity finishes running, the activity contributes only to lifetime and execution time statistics, regardless of whether the option is COLLECT AGGREGATE DATA BASE or COLLECT AGGREGATE DATA EXTENDED when you issue the CREATE SERVICE CLASS or ALTER SERVICE CLASS statement.

The following tables summarize how statistics collection is affected by remapping and collection settings.