Skip to content
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

Define wait times by function instead of variable #18

Closed
cgbystrom opened this issue Jan 13, 2012 · 3 comments
Closed

Define wait times by function instead of variable #18

cgbystrom opened this issue Jan 13, 2012 · 3 comments

Comments

@cgbystrom
Copy link
Member

The current way of specifying the wait time for a Locust makes a rather large assumption on how a developers will want to do this. It assumes that wait time should be randomly distributed in a given interval of milliseconds.

With the current API, a locust with random wait times between 2000 and 5000 ms looks like this:

class User(Locust):
    tasks = [index, stats]
    min_wait = 2000
    max_wait = 5000

However, if we were to replace those hard constants with a function instead, determining that wait time would be a lot easier to both communicate and implement. It would make no assumption on how the developer would like to define his/her wait times and at the same time provide a small, isolated place were this can take place (inside a function). Since randomly distributed wait times within an interval arguably would be the most common, we naturally would ship with some default ones.

Here's an example:

class User(Locust):
    tasks = [index, stats]
    wait_time = random_between(2, 5)

As you can see, wait_time is assigned a function returned by the random_between function. Very straight forward and pluggable. Even simpler than the current implementation as the Locust core would not even need to be aware of how to calculate wait times - just call the wait function to determine the wait time.

Two examples of wait functions that we could ship:

def random_between(from_time, to_time):
    def wait():
        return random.uniform(from_time, to_time)
    return wait

def constant(time):
    def wait():
        return time
    return wait

As with any API changes, discussing them here before diving in. What are your thoughts?

@heyman
Copy link
Member

heyman commented Jan 14, 2012

The intention of the current API isn't that one must specify a range, but rather just a default. To define your own waiting function one would just override the wait function and skip declaring min_wait and max_wait:

class User(Locust):
    def wait(self):
        """ my custom wait function """
        self._sleep(x)

However, I like the wait_time better (as long as the wait function is still there, in case one would like to hook into it), since the user won't need to know about either the sleep function or gevent.sleep().

I also think I like the random_between and constant proposal, but I would prefer the arguments to be specified in milliseconds.

@cgbystrom
Copy link
Member Author

Sure, be aware of the workings of gevent.sleep() feels something only power users should need to worry about.

Regarding milliseconds vs seconds: I see no use of going against the common practice in Python of using the unit of seconds. time.time() and time.sleep() both operate using seconds.

@heyman
Copy link
Member

heyman commented Jan 17, 2012

I think that when specifying two integers, the chance that someone wrongly assumes that it will chose an integer between the two, will increase. I can certainly see myself doing it.

I would prefer milliseconds but it's no deal breaker, since they both work of course :).

pancaprima added a commit to pancaprima/locust that referenced this issue Dec 13, 2017
…locust_files

Add feature: user can choose locust file through web UI
@heyman heyman closed this as completed in 28340a8 Apr 27, 2018
vamega added a commit to vamega/locust that referenced this issue Aug 17, 2018
This allows programmatic usage to collect stats from objects after the locust
run has completed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants