CODEWITHSUNDEEP
azureazure-functionsazure-durable-functions
Tobias von Falkenhayn
Tobias von Falkenhayn

Reputation: 1709

Understanding parallelization of azure orchestration functions

I have some difficulties understanding how azure durable orchestration functions parallelization (and scaling) works under the hood. I am referring to this official document. There it states:

Because the orchestrator and entity function instances are stateful singletons, it's important that each orchestration or entity is only processed by one worker at a time.

What exactly does "orchestration function and entity function instances are stateful singletons" mean when it comes to running multiple orchestration functions in parallel?

Let's say I have a client function which listens to an HTTP trigger and then starts a new orchestration function instance. If I trigger this client function twice, will there be two instances of the orchestration function running with two separate instance IDs in parallel, or will they run in sequence? Will each instance have its own control queue?

Or by taking this example, does CallSubOrchestratorAsync always execute on the same orchestration instance? If so, what's the benefit here since it won't be really running multiple instances in parallel? Or is "parallelization" here just referring to the process of restarting the instance and re-applying the history table based on the different input values?

Upvotes: 2

Views: 1024

Answers (1)

Gandhi
Gandhi

Reputation: 11935

The statement "Because the orchestrator and entity function instances are stateful singleton" is not really valid as you cannot run multiple instances of orchestrator functions if it's a singleton stateful. Ideally, the statement should just say "Because the orchestrator and entity function instances are stateful".

The concurrency throttles link clearly confirms that the orchestrator functions run in concurrency and the concurrency can be limited in host.json. Also, concurrency and stateful singleton are mutually exclusive. So according to me, the statement needs to be corrected.

Also, each orchestration instance may not have its own control queue but each orchestration instance or entity is assigned to a single control queue and it is ensured that only one worker processes this queue so that there won't be any duplication.

To sum up, multiple orchestrations can run in parallel, but within each orchestration, only activity functions run in parallel and the complete orchestration workflow executes serially. Hope it helps.

Upvotes: 2

Related Questions