Implement a spike feature for generateload

[hidenori-shinohara]

Description

Implementation of a spike feature. By setting spikeSize = S & spikeInterval = I, a spike that injects S transactions will occur every I seconds on top of the base rate. Whenever there is no spike, txRate transactions will be injected per second.
For instance, with the command generateload?mode=pay&txs=5000&txrate=3&spikeinterval=4&spikesize=200,

• For most parts, we inject 3 txs/s.
• In the first 3.9 seconds, we inject 3.9 x 3 txs.
• In the first 4 seconds, we inject 4 x 3 + 200 txs.
  ...

until 5000 transactions get injected in total.

Checklist

• Reviewed the contributing document
• Rebased on top of master (no merge commits)
• Ran clang-format v5.0.0 (via make format or the Visual Studio extension)
• Compiles
• Ran all tests
• If change impacts performance, include supporting evidence per the performance document

[marta-lokhova]

two minor suggestions, otherwise looks good to me.

[MonsieurNicolas]

Questions and/or suggestions to simplify

[MonsieurNicolas]

I am not sure I understand the relationship between txRate and spikeSize as written.
txRate is expressed in transactions per second, while spikeSize is a number of transactions per spikeInterval seconds so on can only compare txRate * spikeInterval to spikeSize.

I thought what you wanted to implement was that you'd configure the load generator to generate load with the same average of txRate, but causing a spike of spikeSize every spikeInterval?

So wouldn't the relationship be spikeSize/spikeInterval <= txRate so the test here would really be (spikeSize > txRate * spikeInterval) and when this happens, it's just a warning that the average rate will be higher than expected (and there will only be spikes for the most part)?

That or you can add the spikes on top of the steady rate, and this makes the math even simpler (and in that case, there is no restriction on txRate vs spikeSize).

[hidenori-shinohara]

Thank you for your suggestions!

I changed my code to the "additive" approach (add spikes on top of the steady rate) as this makes the math simpler.

• txRate is the "base" rate of the number of transactions per second.
• A spike will occur every spikeInterval seconds.
• A spike adds spikeSize transactions in one second on top of the base rate. Thus when there's a spike, spikeSize + txRate transactions will be injected in a second.

[MonsieurNicolas]

If you make spikes additive to the base rate, this gets simplified down to txs += bigDivide(elapsedSec.count(), spikeSize, spikeInterval.count(),Rounding::ROUND_DOWN);

which is quite simpler to understand (I'm actually quite not sure the math written here is correct as it's mixing spikeSize and txRate)

[hidenori-shinohara]

It seems to me that the division may need to happen before the multiplication. For instance, if elapsedSec.count() = 1, spikeInterval.count() = 3 and spikeSize = 300, we want to add 0 on this line as we have not had our first spike, but bigDivide(1, 300, 3, Rounding::ROUND_DOWN) would give us 100.

[hidenori-shinohara]

@MonsieurNicolas I updated the code based on our discussion. Specifically, the code used to generate spikeSize txs in one second, but now the code just generates spikeSize txs every spikeInterval seconds, and a spike just happens without being evened out over a second. This made the math simpler. Let me know what you think!

[MonsieurNicolas]

r+ f1247de