Can durable functions performantly fan out to 1,000 concurrent activity functions? Or would using normal functions and fanning out via a service bus queue be better?

Question

We need a process that can fan out many (~1,000) batches of work for parallel processing. I am wondering if fanning out via durable functions vs. via service bus queue entries would be more performant. Is one of these options better suited to this kind of scale? We are using the Elastic Premium (EP2) plan.

Our options as we see them:

Durable Functions

• We would have one orchestrator function create ~1,000 activity functions and await their results.
• We can increase the maxConcurrentActivityFunctions setting if needed, but it looks like max scale-out (100 instances) should accommodate 1,000 parallel activity functions.
• We already use durable functions in our solution, so we could implement this pretty quickly
• We wouldn't have to manage our own queue resource in Azure. It's all behind the scenes in the durable task framework. # Service Bus Queue
• We would have a starter function enqueue ~1,000 messages into a service bus queue. Another function would trigger from that queue.
• It looks like we could tweak the maxConcurrentCalls setting to fine tune our performance
• The local developer experience is poor (from what we've seen) because you need a live service bus queue for testing and development. This is challenging for multiple developers, who may each need their own queue for testing without affecting each other's queue or staging or prod. # Summary

I think we would prefer to fan out using durable functions because the code is easy and there would be no new Azure resources to manage. However, I want to be sure that durable functions are intended to scale to this degree.

Answer 1

Durable Functions should be perfectly capable of handling your scenario. The EP2 plan will scale out to accommodate the activity functions when needed.

But do note that fan-in happens in a single instance as mentioned in the performance docs for durable functions. So, instead of fanning out to one thousand activity function invocations, you could leverage sub-orchestrations to split it into smaller batches.

Answer 2

Hi, @Pramod Valavala . I must admin that the language in that article confuses me a little bit. It speaks of fan-out and fan-in separately, but I've yet to see an example of the former without the latter. I assume it means the following. Can you confirm?

• When fanning out to multiple activity functions, those functions may execute on any number of instances according to scaling rules. However, the process of stitching the results back together is handled by the single orchestrator function which runs on a single instance and may take some time.

If that is accurate, I don't think it's a large concern for our use case. We care more about the performance of scaling out and completing our activity functions, but don't care as much about how long it takes for the orchestrator to fan them in.

Side question: Is it possible to fan-out without fan-in with durable functions?