Scaling orchestrators / entities and activities separately

[yukscck]

Looking at how Durable Functions work, I understand that orchestrators and entity functions work on messages in the control queues, whereas the activity functions work on messages the work item queue.

Would it be possible for me to create 2 separate functionapps - 1 dedicated to executions on the control queues, the other dedicated to executions on the work item queue?

In my project, I have a situation where the executions are expected to be very busy with orchestrating tasks. When there is a high incoming load of executions, the functionapp instances with leases to partitions would be busy orchestrating tasks, but at the same time, still required to process activities from the work item queue - resulting in these different types of functions competing for resources from the same functionapp instance. These are based on what I understand about how Durable Functions work, please correct me if my understanding up to this point is inaccurate.

Understand that we could control the executions by manipulating the maxConcurrentOrchestratorFunctions, maxConcurrentActivityFunctions and partitionCount to control the ratio of instances working on orchestrators and activities. Would this be a way for me to "dedicate" functionapps by role?

Also worth to call out that, however, maxConcurrentOrchestratorFunctions and maxConcurrentActivityFunctions have a minimum configurable value of 1.

Some guidance would be much appreciated.

[cgillum]

Would it be possible for me to create 2 separate functionapps - 1 dedicated to executions on the control queues, the other dedicated to executions on the work item queue?

This is not possible today because each instance of your app will always try to read from both the control queue(s) and the work-item queue. The only time an instance will read from just the work-item queue is if it can't acquire a partition, but even this condition is potentially transient. This is something we'd like to change in the future, but we haven't had a chance to work on this yet.

For now, if you have a strong need to separate your orchestration instances from activity instances, the best practice would be to create a separate function app and put your activity logic there, but as HTTP-triggered functions instead of activity functions (or they could be queue-triggered if you don't need request/response). It's more overhead to do this, but it will guarantee isolation. You can even use the Durable HTTP features if you want to consume these HTTP trigger functions directly from your orchestration logic.

[olitomlinson]

"the functionapp instances with leases to partitions would be busy orchestrating tasks, but at the same time, still required to process activities from the work item queue - resulting in these different types of functions competing for resources from the same functionapp instance"

I was basically asking for the same thing here Azure/azure-functions-host#7142 which was a way for the individual Function App functions to be segregated across host instances based on a hint.

@cgillum fyi