The Recording Performance Analysis

Introduction

One of the keys to the success of any playback is ensuring that you only play back what you really need. This ensures not only that the playback results are relevant, but also that the duration of the playback is not unnecessarily elongated through having to play back unnecessary transactions. The Recording Performance Analysis is a very useful tool to enable you to “trim” the playback of unwanted transactions.

The Performance Analysis Screen

From Recording —> Standard Recordings, go to the Performance Analysis tab and you will be presented with a screen showing relevant information for each object (dialog transaction, batch job, RFC, etc.) that was recorded.

*It is very useful to sort this screen in descending order of steps so that you get information on the most heavily-used objects first.

For each object, the following useful information is shown:

• The number of sessions and steps that called this object
• The current sampling and exclusion status of the object
• Response time (average, min, max, total) information for the object during the recording
• How many unique users called the object during the recording
• Whether or not the object was read only
• Whether or not the object started any outbound RFC calls
  

All of this information can be very useful in determining whether or not a particular object should be included in the playback.

There are also two other pieces of detailed information available.

Record details

By selecting a row and clicking on the Record Details button

You can see the full details of the record.

Clicking on the Single Entry button will show this information in a more easy to read format.

Outbound RFC details

By clicking on the Outbound RFC button:

You can get details of any outbound RFC calls made by the object.

Trimming the playback

There are two ways, from within the performance analysis screen, of trimming objects from the playback.

*The functionality in this area makes use of Filter Sets, so please make sure you are familiar with filter sets, exclusions and sampling before proceeding. Documentation for this functionality can be found in this section of the guide.

Exclusion

By using the exclusion functionality, it is possible to completely remove an object from the playback. For example, if we wanted to completely exclude the Web Service ZSD_GET_PDF_FOR_DOCNO_S from the playback, then we would right-click on the row and choose Exclude from —> Transfer to Repository.

This will add an exclusion to your default filter set and the exclusion will be displayed on the Performance Analysis screen.

*If you know that you will never want to play back this object, then you can also at this point exclude it from future recordings by right-clicking and choosing Exclude from —> Recording

Sampling

If, however, you decide that you still want to test this web service, but that there is no need to execute it over thirty thousand times during the playback, you can instead use sampling. Sampling allows you to only transfer to the repository a percentage of the recorded transactions. So if, for example, we decide that executing this web service 3,000 times will be enough to properly test it, we could sample it so that only 10% of the recorded volume is transferred to the repository and hence included in the playback.

To do this, right-click on the object and choose Sample during —> Transfer to repository —> 10%

Once this has been done, then during the transfer to repository Testimony will randomly select 10% of the recorded transactions to be transferred. The sampling rate is displayed in the Performance Analysis screen.

Determining which objects to trim from the playback

The following are the main things to consider when trying to determine if an object can be trimmed from the playback?

Is it a high-volume read-only object?
Read-only objects that are executed many thousands of time are prime candidates for trimming from the playback. Since they are read-only, we know that they don’t create or change data which subsequent objects may rely on. We therefore need to decide, firstly, whether they should be tested at all. If they don’t need to be tested, then they can be completely excluded from the playback. Secondly, if they should be tested, we should decide whether we need to test the full recorded volume. If not, then we can use sampling to trim the bulk of them from the playback.

Is it a high-volume “read-mostly” object?
Some objects will be listed as Not Read Only, but the value of the number of writes (shown in brackets in the Read Only column) is very low compared to the number of Steps or Sessions. In the example below, we can see that despite there having been over 750,000 steps recorded, only 104 database updates were executed:

By drilling into the details, we can see that these were inserts into the database.

Based on this, we may be able to decide – perhaps after consulting with the technical or functional experts responsible for this object – that in nearly all cases this object is in fact read-only, and can therefore be trimmed from the playback. As you can see, this has been done for this object in the example, where it is being sampled at a rate of 1%.

Does it have outbound RFC calls to a destination that doesn’t exist in the playback system?
At presend, Testimony only supports outbound RFCs on a pilot basis, so in most cases it will be necessary to exclude objects that make outbound RFC calls. By checking the outbound RFC details you can see where the calls are being made to (the RDEST column) and determine if this RFC destination exists in the playback system.