What problem does your feature solve?
Currently Blaster supports a linear and constant pacer. The linear pacer has sufficed, but has its limitations, including:
- target RPS displayed in live logs being an optimistic estimate of the RPS (the logs display the current RPS at five second intervals, but the statistics are for the previous responses, which were assuredly made when the RPS was less than it currently is).
- not straightforward to determine level at which the RPC buckles at if RPS is constantly being increased.
A stepped pacer fixes both of these by incrementing the RPS alongside the logs, so each 5 second window demonstrates how the RPC performs at that level of RPS.
What would you like to see?
A config option that enables a stepped pacer instead of a linear pacer. Currently we just have the --ramp-up <time> flag, but we could add this through --ramp-up <time> --step <step_size> to switch the default linear pacer to a ramped pacer (alternatively, we could make the stepped pacer the default and allow one to use the linear pacer by using a flag like --ramp-up <time> --linear).
To keep the behavior distinct from the linear pacer, I believe the pacer should enforce that it ramps up every 5 seconds. This naturally makes it so each log print represents a different RPS level. It may also be enforced that, when using the linear pacer, step_size * (duration / 5s) >= target_RPS to preserve the ramp-to-constant behavior.
What alternatives are there?
- eliminating the linear pacer entirely. I think it does, however, have its uses -- one can imagine using it with a stepped pacer first to determine the range at which it buckles, then ramping within that range to dial in the buckling point. [Update: in the PR, the linear pacer was removed following team discussion].
What problem does your feature solve?
Currently Blaster supports a linear and constant pacer. The linear pacer has sufficed, but has its limitations, including:
A stepped pacer fixes both of these by incrementing the RPS alongside the logs, so each 5 second window demonstrates how the RPC performs at that level of RPS.
What would you like to see?
A config option that enables a stepped pacer instead of a linear pacer. Currently we just have the
--ramp-up <time>flag, but we could add this through--ramp-up <time> --step <step_size>to switch the default linear pacer to a ramped pacer (alternatively, we could make the stepped pacer the default and allow one to use the linear pacer by using a flag like--ramp-up <time> --linear).To keep the behavior distinct from the linear pacer, I believe the pacer should enforce that it ramps up every 5 seconds. This naturally makes it so each log print represents a different RPS level. It may also be enforced that, when using the linear pacer,
step_size * (duration / 5s) >= target_RPSto preserve the ramp-to-constant behavior.What alternatives are there?