Load Properties, Test Bed Behaviors, and Best Practices

Load Properties (both the load settings and the worker settings) are applied on a per Test Bed Link basis, and each worker works on one LUN / Share at a given time. It is best to think of “load” and “worker” separately. Load is more about controlling the amount of traffic, whereas worker is more about controlling the access to the LUNs / Shares, and that load is divided across the concurrent workers, again on a per Link basis.

Let’s say in a workload you have the following Load Properties settings:

Here are the behaviors for each of the following Test Bed examples.

In the above example, a total of 400MB/s of throughput will be generated, and a total of 100 LUNs will be accessed concurrently by 100 workers (1 worker on 1 LUN at a given time).

In the above example, a total of 800MB/s of throughput will be generated, and a total of 100 LUNs will be accessed concurrently by 200 workers (2 workers on the same 1 LUN at a given time). If you want 256 LUNs to be accessed simultaneously, you will need to set concurrent workers to at least 256.

In the above example, a total of 800MB/s of throughput will be generated, and a total of 100 LUNs from the first FC Service will be accessed concurrently by 100 workers, and a total of 100 LUNs from the second FC Service will be accessed concurrently by 100 workers.

In the above example, a total of 800MB/s of throughput will be generated (400MB/s per port), and a total of 100 LUNs from the first FC Service will be accessed concurrently by 100 workers, and a total of 100 LUNs from the second FC Service will be accessed concurrently by 100 workers.

So if you want to make sure that all LUNs / Shares are getting accessed simultaneously at any given time during a workload run, then you should set the concurrent workers to at least equal to the number of unique LUNs / Shares you have in the Test Bed. For example, if you have 1,000 LUNs / Shares across a number of Targets, a total of 4 external ports (i.e. those facing the clients) on the SUT connected to the Workload Generator over 4 Test Bed Links, and you want to generate a total of 400MB/s of load to the SUT, then you should set the concurrent workers to at least 1,000, and the load to 100MB/s.

Note that the “4 Test Bed Links” can be connected to 1 to 4 Workload Generator Ports, because you can have multiple logical Test Bed Links per Port. For example, you may have a non-contiguous set of client IP addresses you can use for testing purposes, but you don’t have a need to require multiple physical Workload Generator Ports, then you can create multiple Test Bed Links between a Workload Generator Port and the SUT, where each Link has a unique block of client IP addresses.

For FC, using multiple Test Bed Links between a single Workload Generator Port and a single FC Service is not common (or necessary), but is possibly required if you enable NPIV and have some strict zoning configurations.

For FC Test Beds, you might have MPIO enabled. Refer to the Block Protocol SCSI Workloads section and the FC Service (Test Bed) section for more information.