Allow running --no-web in distributed with multiple locustfiles #372
Conversation
…ions to poll for connections between masters and slaves. Also adds options that allow locusts to iterate through all locustfiles and collect stats for each run
justiniso
force-pushed
the
no-web-distributed
branch
from
36f23be
to
5ec19b7
Compare
|
Don't duplicate the same changes across PR's. If the commits you want merged are in this PR, you should cancel your old one. However, by building on previous PR's, your new PR's become increasingly more complex and much harder to review. A better approach would be to break things into a series of small PR's, easing the burden on reviewers and increasing your chances of having your changes accepted upstream. (I realize this is difficult since the maintainers are not merging PR's at the moment). This PR is massive, difficult to review, and risky to merge without tests. bite-sized PR's are the way to go :) |
|
Absolutely agree that smaller pull requests are preferred, but given the state of things, I'm not expecting this one to be merged. Frankly, it needs some cleanup as well as feedback for other use cases. Rather, I'm contributing it as documentation and one possible implementation for a lot of the features and issues that have been piling up here (note the lack of tests and changes to docs). I'm guessing that once the maintainer situation is sorted out whether that's a fork or this same repo, we can approach a better way to deal with the backlog of pull requests. At that point, I think the value of this PR is that it will offer a possible direction for integrating a lot of these feature requests. |
|
@justiniso , That's a good approach to take. I would recommend marking your PR as a "work in progress", so folks know you are not requesting to merge as-is. The convention for that is usually to start the PR description with "WIP", or add tag your PR with a "WIP" label. btw, That's a deficiency in GitHub's PR model. They don't allow you set a status on a PR, which is useful for situations like this. So in order to mark a PR as "work in progress" or "ready for review", you have to rely on comments and labels. Anyways, I'm glad to see some new hackers working on Locust features.. so thanks :) |
|
Thanks for the tip, updated to reflect current status 👍 |
|
Closing for now to revisit best way to do this. |
|
Is there anything that can be contributed to get this in? @justiniso |
WIP, should not be merged yet, but feel free to use for your own projects.
This PR builds on PR's #371 and #333.
It also adresses issues:
#304
#222
#196
#71
With these changes, I am trying to meet the demand for using locust to do load testing as part of a continuous integration pipeline for tools like Jenkins/Bamboo/Travis. While useful for doing manual one-off tests, the current locust version is not conducive for automating a suite of locustfiles to track performance over time.
These improvements allow the user to specify a directory of locustfiles rather than just one (though a single locustfile is still supported). When run in distributed mode using --master with --no-web, the locust master will cycle through each locustfile and have the slaves execute the tasks until either:
On either of these two events, move on to the next locustfile.
Example
On the slaves, run:
On the master:
When the slaves or master are started, both will not begin swarming until the master is online and has made connection with at least 4 slaves (
--min-slaves 4). Once that happens, swarm with 100 clients (-c 100) until a total of 5000 requests are made (-n 5000) or 600 seconds have passed (-t 600). When either of those conditions happen, wait 30 seconds (--cooldown 30) then start swarming the next locustfile with the same parameters. Repeat until this has been done for all locustfiles.