fabcar workload initialisation takes a very long time if the orderer batch size is the 2 second default

[davidkel]

the fabcar workload uses a helper to create the initial cars and is set to create 1000 in the benchmark. The helper code is this

module.exports.createCar = async function (bc, workerIndex, args) {

    while (txIndex < args.assets) {
        txIndex++;
        carNumber = 'Client' + workerIndex + '_CAR' + txIndex.toString();
        color = colors[Math.floor(Math.random() * colors.length)];
        make = makes[Math.floor(Math.random() * makes.length)];
        model = models[Math.floor(Math.random() * models.length)];
        owner = owners[Math.floor(Math.random() * owners.length)];

        let myArgs = {
            contractId: 'fabcar',
            contractVersion: 'v1',
            contractFunction: 'createCar',
            contractArguments: [carNumber, make, model, color, owner],
            timeout: 30
        };

        await bc.sendRequests(myArgs);
    }

Each worker will create 1000 cars at just over 2 second intervals each, meaning it will take a very long time to initialise. We should find a way to ensure this initialisation is very quick, either by not waiting to see if it commits, batching the requests up or getting the chaincode to support batch creation requests.

[aklenik]

Personally, I'm not a fan of putting SUT access code into the initialization phase of workload modules. That function should initialize the workload module itself, process arguments, etc., and not initialize ledger content.

I found that making the ledger content initialization a separate round is cleaner and more flexible. You just define az init round, set its length to N transactions, and you can adjust the rate of loading the ledger through the rate controller.