Playback sampling

Playback sampling was generally availble in v2.12 but not generally available. In Testimony v2.20, it has been significantly enhanced and integrated into the various aspects of the product – in particular the new “Performance Analysis” that happens after the recording.

Conceptually, playback sampling is quite straight-forward. If you record 100,000 steps of the same RFC or web-service, there is not really any need to play them all back if they are read-only (i.e. they do not perform any updates to the database). Thus, it is possible with playback sampling that you can now only execute a smaller % of the total during the playback.

Note that playback sampling is setup within “Filter Sets” which were introduced in Testimony v2.11. The phase at which you do the sampling is typically during the “Transfer to Repository”. So the recording typically captures all 100% of the transactions and then as you transfer to the repository (or the execution queue) you are able to reduce this down by a smaller percentage. Typically the % is between 5% and 20%, but you are able to specify this directly if you wish.

!Important: Note that if subsequent transactions require that these earlier transactions have been executed, then they must be played back. You should not use playback sampling for these objects.

*You can configure playback sampling in two ways, after the recording the “Performance Analysis” or within the “Filter Set” functionality of the configuration.

Playback sampling is configured in Filter Sets

*You can then add entries manually via the create button, or automatically through the performance analysis after a recording.

Addition of a sampling entry to the filter set

*Once you have configured your sampling entries, you will see a reduced set of recorded business transctions transferred to the repository in order to accelerate the speed of the playback sine there is simply not as much to be played back.