In order to facilitate faster playback times, it is now possible to understand what has been recorded from a performance perspective.
When a recording is running, statistics about the recorded objects are captured and aggregated at the object level. These fields include:
- Number of sessions – The total aggregate number of sessions in the recording for the given object
- Number of steps – The total number of steps in the recording for the given object
- Maximum response time – The highest run-time (server response time) of all steps/sessions of the given object
- Minimum response time – The lowest run-time (server response time) of all steps/sessions of the given object
- Average response time – The average response time (server response time) across all steps of the given object
- Total response time – This is the total aggregated time (server response time) across all steps of the given object
- Number of unique users – The count of unique user names that execute this particular object
- Database update information – Provides information on whether the object performs any database inserts, updates or deletes
- Outbound RFC call information – Provides information on whether the obejct makes any outbound RFC calls
This data is now available within a new tab entitled “Performance Analysis” within the “Standard Recordings” area of Testimony. It will only become visible once the recording is turned off.
This data is invaluable in determine which objects should be either excluded from the playback or “sampled” during playback.
More information on sampling is available in this section.
The ability to do this directly from this grid is also available to the operator. A user can either select the object and then the sub-menu item to either exclude or sample or they can right-click on a given row and perform the same.
With regards to exclusions, you can select at which stage you would like to perform the exclusion. Since the object(s) has already been captured in the recording, then excluding during recording is not an option.
Generally, the exclusion would be performed in the next stage after reviewing the recording (i.e. during the transfer to repository).
With regards to sampling, when you specify the object to be sampled, you can specify the amount of sampling to be performed during playback (eg. only play back 10% of the objects).
This is the purpose of the “DB Updates” information that is also output in the performance analysis grid. As shown below, you can select the grid tool-bar buttons for additional information including drilling down on the outbound RFC calls that are made by that object.
When adding object entries for both exclusions or sampling, you can specify into which filter set they will be added.
Additional notes on performance and outbound RFC
Some additional data is also captured regarding whether the object makes any outbound RFC calls during its operation in the recording.
This knowledge is important for playback performance since if the RFC destination on the playback system is not configured correctly – or the external system is not available during the playback, this can lead to extensive delays during the playback.
It is important to analyze the objects listed here that have outbound RFC calls being made. You can drill down on the object to obtain further information including which RFC’s are being called, to which destinations and the volumes involved.
Once you have a complete list of the highest volume entries, you should check that the associated RFC destinations are available within the playback system.
Post your comment on this topic.