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