[mikehorgan-dell]

Summary

With load.op.limit.rate set, every rate-limited run started with a burst. The java-commons RateThrottle that the linear, pipeline and weighted load steps used granted its whole first request at once. The generator's first request is a whole batch (load.batch.size, default 32768 operations), so each node sent up to one extra batch at full speed before pacing began. The throttle's next call then reset its counter, so the burst was never paid back.

A short or slow-object run therefore reported a rate well above its limit. On a three-worker test lab, a 60 s run of 10 KiB writes limited to 8,000 ops/s completed about 20,000 ops/s for its first 4–5 seconds, and averaged 9,562 ops/s (+19.5%).

Each node now paces from its first operation, so the measured rate matches the limit from the start. The limit's meaning is unchanged: operations per second for the step, divided evenly among its nodes.

Changes

• PacedRateThrottle (spt-base, load.generator) implements the java-commons Throttle interface:
  • its clock starts at the first acquisition, which may take one permit; one more permit becomes available each period (1 s ÷ rate, truncated to whole nanoseconds as before);
  • a call never grants more than it requests or than is available, and never a negative count;
  • unused allowance still accrues while the generator cannot output, as before.
• The linear, pipeline and weighted steps construct it in place of RateThrottle. A step without a rate limit constructs no throttle.
• LoadGeneratorImpl is unchanged, apart from a comment. It keeps its clamp of negative counts for other Throttle implementations.

Not changed

• The mixed step ignores load.op.limit.rate, as before.
• In a weighted step, a weight token is still lost when the rate throttle refuses a request (unchanged in steady state).