Skip to main content

Replay Workloads

Replay Workloads are a special category of workloads that replays the exact sequence of commands recorded by a supported source file. Replay workloads are not workload models, and do not generate IOs based on percentage distributions like the Storage Protocol Workloads.

Replay Workloads can only be created from the Workload Data Importer workflow.

Once a supported data source file is imported into Workload Data Importer, the output will be a Replay Workload.

Design Limits and Behaviors

The amount of time it takes to analyze the imported per-command trace data increases as the imported file's table size increases. To give some idea of how long it takes to analyze a CSV file of certain size, here are some internal benchmarks that were observed:

  • 4MB CSV file: ~1 minute

  • 40MB CSV file: ~2 minutes

  • 400MB CSV file: ~25 minutes

The exact analysis time you experience may be different from what was described above, depending on the exact number of rows in the CSV file, the number of columns, and what else WorkloadWisdom is doing at the time.

A maximum file size of 1GB is recommended, because there is an upper limit of 1GB per Workload Generator Port that stores the entire command sequence that the Port will be responsible for generating. In the event you import a CSV file that is larger than 1GB, there is still a possibility that it will be accepted as the imported data is transformed to a file that gets loaded to each Workload Generator Port, and usually it is a smaller file size than the original imported data file.

There is also a product wide maximum import size of any file into WorkloadWisdom. See Design Limits and Support.

The Duration of the Replay Workload Test Run is automatically calculated based on the information provided in the imported workload data file, and the number of cycles, rounded up to the nearest second. Therefore, you do not need to specify the Duration of the test run like other workloads.

Replay Workload Options

2019-11-18_12-48-05.png
  • Cycles. The number of times the workload will repeat itself.

  • Gap between Cycles (sec). The number of seconds to wait before starting a new cycle.

  • LBA Offset. The LBA offset, in number of blocks, added to the recorded LBA each time a new cycle begins. Leaving it at 0 can cause the SUT to cache the data as the same data can appear on the same block every cycle. Setting it to a non-zero value will cause the LBA of a command to shift by that non-zero value each cycle. For example, if a recorded command's LBA is 2,048, and the LBA Offset is 2, then during the first cycle, the command will carry an LBA of 2,048 + 2 * block size, then during the second cycle, the command will carry an LBA of 2,048 + 4 * block size, then during the third cycle, the command will carry an LBA of 2,048 + 6 * blocksize.

  • Max Concurrent Threads. The maximum number of threads that can run concurrently. Each Thread works on a specific LUN. So if you have 10 LUNs, then you should have at least 10 concurrent threads. Generally, it is ok to set it at 2,048, which is the maximum value.

Original Trace File Info

2019-11-18_12-56-19.png

The Original Trace File Info section is a read-only section that gives you high level summary of the imported trace file, which will be helpful when selecting a Test Bed ITLs for the Replay Workload Test Run.