Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix VariableArrivalRate not working well
The previous implementation worked basically as follows: A list of changes to the arrival rate is generated where there is a minimum time between this changes (currently 250ms). This means that for any ramp-up/down there is a step every 250ms (more or less). After this is generated a goroutine will read that list and send the change on a channel at the appropriate time. During ramp-up/down this is every 250ms (more or less). Another goroutine will be receiving those changes and resetting a timer to the new value. And here is where the problem lies: If the arrival rate is more then 1 iteration each 250ms this means that it will never trigger a start of a VU. The extreme example is having ramp-up to 4 iteration per second - this is exactly 1 iteration each 250ms, which means that for the whole duration up to end of the ramp up there will be zero iterations started. The new design changes only the last part of how VariableArrivalRate Executor works. Instead of reseting the timer to the new value we calculate what the value should be given how much has passed since the last itearation in order to compensate, example: If the last iteration was 300ms ago and the new rate is 320ms then the timer is reset to 20ms at first and then to 300ms after each iteration is triggered. Of course there is the complication that we can have the situation in which we already needed to make a iteration given that and that we should start the next iteration not 320ms from when we get the new time between iterations but after that 1 iteration we do 20ms from that time ... So the code got hairy. The even bigger problem with the code (apart from it probably needing to be split in more functions or reorganised totally differently). Is that this makes it even harder to solve the problem where splitting the test in multiple execution segments won't keep the timing of individual iterations instead it will group them in time, as shown and reported in #1007
- Loading branch information