Concurrency settings for activity functions in a durable function on Flex Consumption Plan

Question

I have an Azure Functions Durable Function, written in Python, that I have migrated from a Consumption Plan to a Flex Consumption Plan. I am trying to understand the available concurrency settings.

On the Consumption Plan, you could set FUNCTIONS_WORKER_PROCESS_COUNT and PYTHON_THREADPOOL_THREAD_COUNT to determine the per-worker configuration. On the Flex Consumption Plan, FUNCTIONS_WORKER_PROCESS_COUNT is no longer available.

Is the implication of this that the Flex Consumption Plan will always use 1 worker process per instance, and the durableTask/maxConcurrentActivityFunctions should always be limited to thePYTHON_THREADPOOL_THREAD_COUNT ?

Or can I set durable as a --trigger-type and set perInstanceConcurrency with az functionapp scale config set?

Or something else?

Source material:

• Azure Functions Flex Consumption plan hosting
  • This per-function scaling behavior is a part of the hosting platform, so you don't need to configure your app or change the code. For more information, see Per-function scaling in the Event-driven scaling article.
  • Scale groups: Durable Functions, Triggers in group: Orchestration trigger, Activity trigger, Entity trigger, Settings value: durable
  • Source: https://learn.microsoft.com/en-us/azure/azure-functions/flex-consumption-plan#per-function-scaling
• Event-driven scaling in Azure Functions:
  • "The Flex Consumption plan is unique in that it implements a per-function scaling behavior. In per-function scaling, except for HTTP triggers, Blob (Event Grid) triggers, and Durable Functions, all other function trigger types in your app scale on independent instances."
  • "The two Durable functions (function3 and function4) both run together on their own instances and scale together based on configured concurrency throttles."
  • Source: https://learn.microsoft.com/en-us/azure/azure-functions/event-driven-scaling?tabs=azure-cli#per-function-scaling
• Performance and scale in Durable Functions (Azure Functions)
  • "Activity, orchestrator, and entity function concurrency limits can be configured in the host.json file. The relevant settings are durableTask/maxConcurrentActivityFunctions for activity functions and durableTask/maxConcurrentOrchestratorFunctions for both orchestrator and entity functions. These settings control the maximum number of orchestrator, entity, or activity functions that are loaded into memory on a single worker."
  • Source: https://learn.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-perf-and-scale#configuration-of-throttles
• Improve throughput performance of Python apps in Azure Functions
  • By default, every Functions host instance has a single language worker process. You can increase the number of worker processes per host (up to 10) by using the FUNCTIONS_WORKER_PROCESS_COUNT application setting. Azure Functions then tries to evenly distribute simultaneous function invocations across these workers.
  • You can set the value of maximum workers allowed for running sync functions using the PYTHON_THREADPOOL_THREAD_COUNT application setting. This value sets the max_worker argument of the ThreadPoolExecutor object, which lets Python use a pool of at most max_worker threads to execute calls asynchronously. The PYTHON_THREADPOOL_THREAD_COUNT applies to each worker that Functions host create
  • Source: https://learn.microsoft.com/en-us/azure/azure-functions/python-scale-performance-reference#use-multiple-language-worker-processes

Answer 1

Hello @David Meltzer

On the Flex Consumption Plan, the FUNCTIONS_WORKER_PROCESS_COUNT setting is not available, so the implication is that the plan will always use one worker process per instance.

Therefore, the durableTask/maxConcurrentActivityFunctions should be limited to the PYTHON_THREADPOOL_THREAD_COUNT.

You can set the durable trigger type and set perInstanceConcurrency with az functionapp scale config set to configure the concurrency limits for the Durable Functions.

Alternatively, you can also configure the concurrency limits for activity, orchestrator, and entity functions in the host.json file using the durableTask/maxConcurrentActivityFunctions and durableTask/maxConcurrentOrchestratorFunctions settings.

These settings control the maximum number of orchestrator, entity, or activity functions that are loaded into memory on a single worker. Please note that the language runtime you select may impose strict concurrency restrictions on your functions. For example, Durable Function apps written in Python or PowerShell may only support running a single function at a time on a single VM. If the language runtime you are using places a restriction on concurrency, you should update the Durable Functions concurrency settings to match the concurrency settings of your language runtime.

---

This should get you started.

Answer 2

Is the implication of this that the Flex Consumption Plan will always use 1 worker process per instance, and the durableTask/maxConcurrentActivityFunctions should always be limited to thePYTHON_THREADPOOL_THREAD_COUNT ?

Yes, the Flex Consumption plan will always use 1 worker process per instance. PYTHON_THREADPOOL_THREAD_COUNT currently defaults to 1000 but it will smartly reuse threads.

Or can I set durable as a --trigger-type and set perInstanceConcurrency with az functionapp scale config set?

The only trigger type supported for this perInstanceConcurrency setting is http. For Durable the concurrency is set in host.json as pe what you found. As per the doc, the relevant settings are durableTask/maxConcurrentActivityFunctions for activity functions and durableTask/maxConcurrentOrchestratorFunctions for both orchestrator and entity functions. In Flex Consumption these settings control the maximum number of orchestrator, entity, or activity functions that are loaded per instance of the app, and therefore tell the app how to scale (i.e., if there's 10 activities created at the same time but the activity concurrency is set to 1, you should see the app scale to ~10 instances).

Answer 3

Please note that the language runtime you select may impose strict concurrency restrictions on your functions. For example, Durable Function apps written in Python or PowerShell may only support running a single function at a time on a single VM. If the language runtime you are using places a restriction on concurrency, you should update the Durable Functions concurrency settings to match the concurrency settings of your language runtime.

Where can I find the concurrency restrictions for the language runtime (Python in my case) ?

"...may only support a single function.." is a bit vague and ambiguous.