4 ms·
a run is a workflow run. The demo video i recorded for example would be 1 run. This way of measuring things is kind of falling apart because people can nest au
by murb 3y ago
a run is a workflow run. The demo video i recorded for example would be 1 run.
This way of measuring things is kind of falling apart because people can nest automations and loop them to run many times on many values. One 'run' of a heavily nested automation could actually lead to hundreds of runs do to nesting.
My co-founder and I have debated this at length and the only way we see to solve this is to add a credit based system and stop caring about runs altogether. Each node would have a credit cost and each plan would have monthly credit alotment. If you can think of a better way we're very open to suggestions!
- frabjoused 3y agoYeah, I would do either node runs or track CPU time / memory and abstract it to credits, as you were mentioning. Can I ask how your runs are executed? I'm assuming tracking usage is probably trivial, if you're running each process in individual sandboxes.
- murb 3y agoEach node in our backend has a cost associated with it that we defined on a 0-100 scale. Our plan is to aggregate those at the end of a run to determine it's cost. Tying that cost to some actual metric like CPU usage could be a great idea though. Runs are basically dynamically generated scripts. Our backend parses the automation definition from the DAG on the frontend, fetches the definitions of each node and stitches it all together to run in a sandbox env. It started off quite simple in the early days but it's become quite an monstrous system with dynamic variables, nesting, looping, credential access and error handling.
- frabjoused 3y agoThat's how it goes! If you're not already doing it, you're going to want to eventually make sure every Run is done independently. Parallel runs between multiple clients isn't going to fly as your load picks up.