-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Possibility to set the exact number of users to spawn (instead weight) #1939
Comments
Hi I was thinking about the same feature - I talked a little bit with @mboutet about it and discussed how to implement it and we came to the following design:
and then modify algorithm of spawning in dispacher with following rules:
Code is not checked - I didn't have time to do it yet, but if somebody is available to do it - go ahead. Cheeers, |
Looks like a reasonable approach. If someone makes a PR with a few appropriate tests I’ll be happy to review. |
After diving into code I realized what my previous comment was pretty senseless. I have deleted it. )) After experiments, I also realized that in the current implementation of user spawning, trying to generate them more evenly, they still have to give large weights, although I achieved some success and even wrote part of the tests, my implementation's behavior close to generating fixed users at first. So I back to the @marcinh realization, with some modification to resolve case with restore fixed users count after ramp-down and ramp-up. |
Is your feature request related to a problem? Please describe.
I needed a special query that would be executed once every 30 seconds, regardless of the total number of users created. The only solution I came up with is to create one instance of a user with such a request. To do this, it was necessary to count his weight according to the formula
This is not very convenient not very obvious.
Describe the solution you'd like
Just a field (like weight) "count" or "fix_count", which describes the exactly count of user instances. I guess weight parameter in that case have to be ignored.
Describe alternatives you've considered
Additional context
If you find it a useful figure I can try to do
The text was updated successfully, but these errors were encountered: