why is the time it takes to start the subflows, proportional to the amount of subflows submitted concurrently? seems like it is about 30 seconds per each subflow. The subflows are started as subprocesses in the parent flow process. could this be a misconfiguration or something else? this is reproducible and I am well below the concurrency limits

hi @Lev Zemlyanov yes this

why is the time it takes to start the subflows, proportional to the amount of subflows submitted concurrently?

should not be true in general, I would suspect its about the specific subflow you're trying to run

@Nate thanks for the prompt response, do you have any indication why this could occur? seeing this regularly where a deployed flow is started, and all of the rest are started only after a minute or more of waiting, but they are all submitted concurrently using a thread pool

there are many reasons this could happen but its hard to say what it is without seeing the code, seems like resource contention of some kind between the things you're hoping would run concurrently

im sorry i posted the wrong screenshot