Performance Analysis

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.

Performance analysis after a recording

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

!Important! Sampling should only be performed for objects that do not update the database. If database updates are made, then you need to be certain that they are not critical for subsequent transactions that may rely upon these transactions having happened (otherwise they may subsequently fail as well).

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.

Toolbars availble in performance analysis

When adding object entries for both exclusions or sampling, you can specify into which filter set they will be added.

*Top Tip: After a recording has completed, this should be your first port of call to understand what has been captured. You should start by sorting the entries shown in the performance analysis grid by the total number of sessions (or steps). The highest volume entries are good candidates for sampling during the playback so that not everything is played back. Your next step should be to sort by the total response time. This will show you the problematic objects that might cause issues from a performance perspective during the playback. These become candidates for sampling but may also be candidates for exclusion. You might also like to use the sorting by maximum response time as this will high-light anomalies in the playback where a particular long running batch job might cause issues.

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.

!Example scenario – We have seen issues with outbound RFC causing major performance issues with playbacks. The situation that had occurred was a particular batch job that ran every 10 minutes in production that was recorded. Each job duration was approximately 10 seconds. However, when executed in the playback system, this run-time was over 45 minutes. It was traced back to outbound RFC calls being made and since the external system was not available during the playback, the RFC call would time-out after 1 minute. However, since there were 50 calls in each run, then the job run-time during the playback became 50 minutes.

*Outbound RFC service virtualisation is not in general release with Testimony v2.20. Outbound RFC service virtualisation will help considerably in this circumstance and advice on this will be updated at the time of general availability.