locustio / locust

Write scalable load tests in plain Python 🚗💨
https://locust.cloud
MIT License
25.06k stars 2.99k forks source link

Request: support concurrent and hatch for web-based startups #153

Closed jpotter closed 7 years ago

jpotter commented 10 years ago

We use a supervisor to start processes and services in our setup. It'd be nice for us to be able to use -c and -h with the web interface, so that our dev installs, when they start up, automatically start load testing, and our devs can go and look at the web interface to see what's going on. Is this something that's easy to do? It's not clear why the "--no-web" restriction exists on those flags (other than it's something most installs wouldn't generally use).

Thanks!

sanga commented 10 years ago

This is obviously a workaround, but there's nothing to stop you from just starting locust and then calling curl to http://locusturl/swarm (in so doing providing hatch_rate and max_locusts). That's how we run locust tests automatically (with slaves which requires the web interface).

jpotter commented 10 years ago

Thanks, Tim -- that certainly works; and I'll do that for our system.

I'm going to leave this issue open in case other users want similar functionality, and leave it to whomever's discretion as to whether it should be closed as "won't fix" or tagged as "feature request".

-Jeff

heyman commented 10 years ago

They exist for the --no-web parameter because there is no other way of specifying the number of users and hatch rate without the web UI.

Even though it would be easy to make the -c and -r options work with the web UI as well, it wouldn't work when running Locust distributed. I agree that it would be nice to have them work without the --no-web as well, but then I would really like them to work when using a master/slave setup as well, and unfortunately I can't see a clean way of implementing this. Either we would have to add a new parameter that would tell the master how many slaves to expect (and it would wait with starting the swarm until that many slaves had connected), which doesn't seem like a nice solution. Or we would have to change master/slave implementation into a less simple/dumb solution, where one could connect more slaves while a test is running.