Generating workload and measurements

Included within this ordering service is a special java client that can emulate the behavior of frontends issuing heavy workloads, in order to produce throughput and latency measurements related to the ordering nodes. It can be used with the default crypto material and "SampleOrg" organization of the ordering nodes. To launch this client, use the startWorkload.sh script from within a bftsmart/fabric-tools container with the following parameters:

$ starWorkload.sh <frontend ID> <channel ID> <num workers> <payload size> <txs per worker> <random|unsigned|signed> <delay (ms)>

<frondend ID> is supposed to be one of the IDs within the RECEIVERS parameter in ./config/node.config, but you can supply an ID that is not supposed to be a frontend. If you do so, the client will still contribute with workload, but will not be able to receive blocks, thus won't be able to collect latency measurements at the client.

<channel ID> is an ID for any channel that has already been created. Normally it is simply the system channel ID.

<num workers> is the amount of bftsmart clients that effectively send transactions to the ordering nodes. These are equivalent to the connection pool for normal frontends.

<payload size> is the size of the transaction. These transactions are just a 4-byte hashcode that the clients will later use to identify the timestamp at which the transactions were sent, in order to calculate latency values. If you supply a size larger than 4 bytes, the rest of the transaction will be padded with random data. This means transactions will always have a minimum of 4 bytes.

<txs per worker> is the amount of transactions each bftmart client will send. Hence the total amount of transactions sent will be <num workers> X <txs per worker>

<random|unsigned|signed> lets you specify how do you wish to encapsulate the transactions. "signed" is used to create signed Fabric envelopes containing each transaction. "unsigned" creates unsigned envelopes. If you use this option, you will need to set ENV_VALIDATION at ./config/core.config to "false". "random" will simply send the transactions as they are with no encapsulation. If you use this option, you will need to set both FILTER_MALFORMED and ENV_VALIDATION to "false".

<delay (ms)> is the amount of time each worker will wait before sending the next transaction, in miliseconds.

Ordering nodes will store throughput results at the main folder in a file called throughput_<NODE ID>_log. By default the log looks like this:

2018-XX-XX 16:08:29.785    envelopes/second    17580.871
2018-XX-XX 16:08:31.663    envelopes/second    26752.273
2018-XX-XX 16:08:33.611    envelopes/second    25667.352
2018-XX-XX 16:08:34.794    envelopes/second    42301.184
2018-XX-XX 16:08:36.050    envelopes/second    39808.918
2018-XX-XX 16:08:37.669    envelopes/second    30883.262
2018-XX-XX 16:08:39.169    envelopes/second    33333.332
2018-XX-XX 16:08:40.569    envelopes/second    35739.812
2018-XX-XX 16:08:41.775    envelopes/second    41493.777
2018-XX-XX 16:08:43.347    envelopes/second    31806.615
2018-XX-XX 16:08:44.836    envelopes/second    33602.152
2018-XX-XX 16:08:46.354    envelopes/second    32959.79
2018-XX-XX 16:08:46.515    blocks/second    2555.4534
2018-XX-XX 16:08:47.763    envelopes/second    35511.363
2018-XX-XX 16:08:49.049    envelopes/second    38910.504
2018-XX-XX 16:08:50.504    envelopes/second    34364.26
2018-XX-XX 16:08:52.837    envelopes/second    21440.824
2018-XX-XX 16:08:54.204    envelopes/second    36683.785
2018-XX-XX 16:08:55.486    envelopes/second    39001.56
2018-XX-XX 16:08:57.007    envelopes/second    32894.74
2018-XX-XX 16:08:58.313    envelopes/second    38314.176
2018-XX-XX 16:08:59.783    envelopes/second    34036.758
2018-XX-XX 16:09:00.832    blocks/second    3492.3518

envelopes/second is the throughput for envelopes that arrive from the ordering protocol, whereas blocks/second are the blocks generated per second. To obtain the transactions/second from this data, multiply "blocks/second" by the number of transactions present in the blocks (specified when generating the genesis block, at configtx.yaml, parameter MaxMessageCount). By default the value of MaxMessageCount is set to 10. This means that in the sample above, the service has generated close to 35 thousand transactions per seconds from 16:08 to 16:09.

The workload client will store latency results at latency_<FRONTEND ID>.log. The format is similar to the log above. The results are given in miliseconds. You can edit the format of the logs at ./config/logback.xml at both the nodes and clients.