You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 24, 2020. It is now read-only.
Currently steps are asynchronous. so, if you want to run them asynchronously, you can cheat the system by adding a staggered interval "run_delay" to each consecutive step. To prevent overlap, I usually also add in an additional 30 second delay. This has the same effect as running each step back-to-back (more or less), but is a bit cumbersome to calculate and re-calculate the run delays when you wish to increment the step run durations.
The other side-effect of this is that the broker assumes you need all the instances for each step up front (which isn't true if you're running the steps back-to-back). For example, if I have 3 steps that require 1, 2 and 3 attack nodes (per step) respectively, the broker sets up 6 nodes up front. This isn't a big deal for small attack swarms, but can get close to AWS quotas for larger swarms if we don't manage this more efficiently.
This is what we're currently hacking on for Firefox Send and Voice Fill (formerly "Speak To Me"). It is super easy to tweak some process/worker counts and durations without the need to recalculate run delays and start times.
porting over feature request from loads-broker: loads/loads-broker#102
Currently steps are asynchronous. so, if you want to run them asynchronously, you can cheat the system by adding a staggered interval "run_delay" to each consecutive step. To prevent overlap, I usually also add in an additional 30 second delay. This has the same effect as running each step back-to-back (more or less), but is a bit cumbersome to calculate and re-calculate the run delays when you wish to increment the step run durations.
The other side-effect of this is that the broker assumes you need all the instances for each step up front (which isn't true if you're running the steps back-to-back). For example, if I have 3 steps that require 1, 2 and 3 attack nodes (per step) respectively, the broker sets up 6 nodes up front. This isn't a big deal for small attack swarms, but can get close to AWS quotas for larger swarms if we don't manage this more efficiently.
Example scalability test:
The text was updated successfully, but these errors were encountered: