Cadence configuration for worker threads and workflow

Question

What will be the  ratio between worker and workflow and how to manage the threads so that there should not be outage between workers and number of workflows If I start more number of workflow following error is thrown

Not enough threads to execute workflows. If this message appears consistently either WorkerOptions.maxConcurrentWorklfowExecutionSize should be decreased or WorkerOptions.maxWorkflowThreads increased.

the workflow in blocking state remains active in memory ?? Workflow in await state continuously checks for condition ??More the number of workflow in await state will keep worker occupied ?? In below example the thread is waiting for a signal,  the number of workflows is scaled to a million/day and timetocloseWorkflow = 2days. And the average time to trigger a signal is 1 day after the respective workflow is started

public class TestWorkflowImpl implements TestWorkflow {

 private static final Logger logger = LoggerFactory.getLogger(TestWorkflow.class);
 private int counter = 0;

 private final CounterPrintActivity cpa = Workflow.newActivityStub(CounterPrintActivity.class);

 @Override
 @WorkflowMethod
 public String startWorkflow() {
 Workflow.await(() ->counter >= 1000);
 return "Complete";
 }

 @Override
 public int getCurrentStatus() {
 return counter;
 }

 @Override
 public void setCount(int setNum) {
 logger.info("In signal");
 counter = counter+setNum;
 }

--

Answer 1

What will be the ratio between worker and workflow and how to manage the threads so that there should not be outage between workers and number of workflows If I start more number of workflow following error is thrown

There is no such ratio as blocked workflows don't consume worker memory at all (after they are pushed out of cache). So it is possible to have billions of blocked workflows and a single worker if those workflows don't make any progress.

Not enough threads to execute workflows. If this message appears consistently either WorkerOptions.maxConcurrentWorklfowExecutionSize should be decreased or WorkerOptions.maxWorkflowThreads increased.

maxWorkflowThreads defines how many threads all currently executing and cached workflows can use.

maxConcurrentWorklfowExecutionSize defines how many workflow tasks can execute in parallel.

The "Not enough threads to execute workflows" exception indicates that there are not enough threads to execute currently running workflow tasks. For example, if each workflow uses two threads and maxConcurrentWorklfowExecutionSize is 100 then maxWorkflowThreads should be at least 200. With such setup 0 workflows will be cached as all the threads would be consumed by the currently executing workflow tasks. So in general it is better to keep maxWorkflowThreads much higher than maxConcurrentWorklfowExecutionSize to support caching.

the workflow in blocking state remains active in memory ??

It remains cached until another workflow needs to make progress and kicks the cached workflow out. After that, the blocked workflow is loaded into worker memory when it receives some new event like timer, signal, or activity completion.

Workflow in await state continuously checks for condition ?? More the number of workflow in await state will keep worker occupied ??

It checks only when some new event is processed. When nothing is happening the check is not executed.

In below example the thread is waiting for a signal, the number of workflows is scaled to a million/day and timetocloseWorkflow = 2days. And the average time to trigger a signal is 1 day after the respective workflow is started

This scenario should work fine assuming that workers can keep up with the workflow task processing rate.