You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, thank you that you are investing your time for this great tool!
Proposal
vegeta should have an option to ramp up the rate at the start. Example: rate of 200 is given and rampup of 10 seconds is given - than vegeta increase the rate of 10% per second:
first second: 10% - rate=20
second second: 20% - rate=40
...
tenth second: 100% - rate=200
command could be as followed:
-rampup int
seconds to ramp-up the target-rate
That option would allow to attack/test targets more naturally, since traffic (at least on our servers) does not increase that much from one second to the other.
Background
I just tested some webserver-configurations and optimized them. webservers cannot handle the traffic-jump (like 10 rq/s to 1,000rq/s in less than a second), because they need to spawn extra workers and so on. Without the rampup the report is falsified, since the webservers needs some seconds to scale.
Workarounds
I'm not aware of a workaround.
The text was updated successfully, but these errors were encountered:
I also wrote a RampPacer that does something similar to what you describe if you're interested in looking into the code, but it is used as a lib and not as a vegeta command.
Hi, thank you that you are investing your time for this great tool!
Proposal
vegeta should have an option to ramp up the rate at the start. Example: rate of 200 is given and rampup of 10 seconds is given - than vegeta increase the rate of 10% per second:
first second: 10% - rate=20
second second: 20% - rate=40
...
tenth second: 100% - rate=200
command could be as followed:
That option would allow to attack/test targets more naturally, since traffic (at least on our servers) does not increase that much from one second to the other.
Background
I just tested some webserver-configurations and optimized them. webservers cannot handle the traffic-jump (like 10 rq/s to 1,000rq/s in less than a second), because they need to spawn extra workers and so on. Without the rampup the report is falsified, since the webservers needs some seconds to scale.
Workarounds
I'm not aware of a workaround.
The text was updated successfully, but these errors were encountered: