It'd be nice if we were able to parametrize custom LoadTestShapes. For example control peak number of users or test duration as a whole.
I want to measure resources utilization for different amount of users. To achieve that I've prepared usage characteristics from our logs and want to see how much more users we can support with current hardware. To do that I want to test my service with different peak user counts - e.g. 1k, 2k, 3k, etc. For now it's really frustrating to do because I always need to change that value in file.
I'd be nice if we were able to access some kind of context information from LoadTestShape that could contain configuration in form of simple dictionary. e.g.
def tick(self):
max_users = self.context.parameters['max_users']
...
Parameters could be set via HTTP form <input name="load_parameter[max_users]" /> or CLI parameter: --load-parameter max_users=200.
HTTP form could be changed by wraping it with some block and thus allowing to easily overwrite it with custom form.
For CLI usage probable environment variables would be good enough, but for HTTP it's not really viable - especially because we're using k8s.
I thought a request like this might come, overall I think it's a good idea, just not sure how to implement it in an elegant way.
or CLI parameter: --load-parameter max_users=200
For CLI usage probable environment variables would be good enough
If you want to pass parameters to your LoadTestShape then there's nothing stopping you just use environment variables and then get them in your LoadTestShape with os.environ['MY_SHAPE_OPTION']. It's functionally the same and doesn't require locust to have some complicated CLI args.
HTTP form could be changed by wraping it with some block and thus allowing to easily overwrite it with custom form.
I was thinking more of this.Perhaps a text box in the UI that is passed raw to the load test and then it's up to you to parse it in your LoadTestShape. Still I think it's not super elegant at this point, passing data to the loadtest via HTML 🙂
Thanks for replying!
there's nothing stopping you just use environment variables and then get them in your LoadTestShape with os.environ['MY_SHAPE_OPTION']
Yeah, but this only works in CLI scenario, where we are rerunning locust for each test. In theory it could also work with HTTP but we would have to restart the server after each test - which basically is not ideal, that is why we rejected this idea.
Another possibility would be to create custom page with form and mutate config from that page (and this is probably method that i will choose as workaround), but ideally it should be possible to hook into start dialog i think.
@kadet1090
Yeah, but this only works in CLI scenario
Yes, true
Perhaps a text box in the UI that is passed raw to the load test and then it's up to you to parse it
What do you think about this idea?
Perhaps a text box in the UI that is passed raw to the load test and then it's up to you to parse it
What do you think about this idea?
I don't presonally think that this is best possible solution, but for sure is good enough and probably needs the least amount of work. We would however have to have some kind of def parse_properties(self, properties: Str) method that will be called at start of each test as parsing it inside tick() could have nagative impact on performance.
I don't presonally think that this is best possible solution
But it's what you meant when you said this?
Parameters could be set via HTTP form
Or did I misunderstand? 🙂
I tought more about being able to overwrite actual form and provide our own html (via template extending, for example, or some other way):
{% extend 'path/to/templates/index.html' %}
{% block swarm_form %}
<label for="peak_count">Number of peak users to simulate</label>
<input type="text" name="parameter[peak_count]" id="peak_count" value="1000" class="val"/><br>
<label for="total_time">Total time of the load (in seconds)</label>
<input type="text" name="parameter[total_time]" id="total_time" value="600" class="val"/><br>
{% endblock %}
And it would look like this:

It'd require change to templates/index.html by wraping it with {% block swarm_form %}{% endblock %}. Then everything that was sent by form inside parameter dictionary should be accessible to LoadTestShape.
By default we could of course just display <textarea name="parameter[data]"></textarea> that could be parsed - so if someone for any reason don't want to be bothered with HTML modification.
I could try to achieve something like that in free time, and give you some kind of response how hard was to implement that (eventually submit PR if it'd be good enough) :)
OK I see. Sounds good. There was some previous PR IIRC about making the UI more editable.
Most helpful comment
I tought more about being able to overwrite actual form and provide our own html (via template extending, for example, or some other way):
And it would look like this:

It'd require change to
templates/index.htmlby wraping it with{% block swarm_form %}{% endblock %}. Then everything that was sent by form insideparameterdictionary should be accessible toLoadTestShape.By default we could of course just display
<textarea name="parameter[data]"></textarea>that could be parsed - so if someone for any reason don't want to be bothered with HTML modification.I could try to achieve something like that in free time, and give you some kind of response how hard was to implement that (eventually submit PR if it'd be good enough) :)