Consider the case where there is one parent process that want to farm out a lot of (similar) work in parallel to different machines. For example, an insurance company that wants to re-process 1000 applications. If the re-processing of an application is CPU, memory, or time intensive, then it makes sense to distribute this work to multiple machines.
Or perhaps you have a system that needs to process 1000 things, where each thing takes 10 seconds, in a total of 10 seconds. In this case, if each machine has 10 threads available, then you would run on 100 machines at the same time.
It seems that currently the optimization puts all 1000 jobs on the same machine as the parent process.
I do understand that once the max pool configuration thread count is exceeded, it will force other nodes to pick up the jobs, but in my case this is inefficient because all of my processes have an async-before on the start event. This means that the only way I can force them to distribute is to introduce an artificial sleep as the first step in the process. This sleep forces it into N active threads, and when N exceeds the maxPool count, only then does it distribute to other nodes.
So lets say I have machine A and machine B. It goes something like this:
- A runs parent process
- A executes multi-instance call activity (1000 parallel jobs)
- Optimization hints to A to message the start of 1000 jobs on A
- A starts 1000 rows, immediately going right back to the database 1000 times.
- Optimization re-hints to A to pick up more jobs immediately
- A gets N threads into an active state (where N is defined in the process engine configuration)
- Now, the rest of the jobs start to get picked up by B at B’s next acquisition time
NOTE: We require async-before on all process definition start events, so that every process start is audited / recorded in the database.