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 Sep 26, 2022. 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.
The text was updated successfully, but these errors were encountered:
rpappalax
changed the title
Steps should be able to be run either synchronously or asynchronously
Add ability to run broker either synchronously or asynchronously
Mar 9, 2017
rpappalax
changed the title
Add ability to run broker either synchronously or asynchronously
Add ability to run broker steps synchronously or asynchronously
Mar 29, 2017
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: