Cold start performance impact of DurableTask extension when no orchestrations created

[nazar-kuzo]

Hi,

I have two separate Azure Function applications API + Automation, where

• API part is lightweight REST API that serves client requests
• Automation is internal application that does all async request processing.

The typical workload is that users work with API application only to query job statuses and scheduling new job, but API application itself is delegating all the work to Automation application. I try to keep API application as lightweight as possible to ensure that startup times are low.

I would like to understand what cold start performance impact of DurableTask extension will be when I add it to API application and won't have any of orchestration/activity functions there but simply use IDurableClient as a facade to talk to Automation application: schedule new orchestration or query existing orchestrations status.

What would be recommended way to have API application as lightweight facade that communicates with heavy Automation application with dozens of orchestration/activity functions in order to query status or start new orchestration without bloating API application with redundant packages and affecting cold start performance due to full-featured DurableTask extension?

Thanks!

[ltouro]

You don't really need anything from DurableTask in your API initialization.

Just the DurableClient, which should be very lightweight. Check AddDurableClientFactory in https://learn.microsoft.com/en-us/dotnet/api/microsoft.azure.webjobs.extensions.durabletask.durabletaskjobhostconfigurationextensions.adddurableclientfactory?view=azure-dotnet

[ltouro]

Then, in the Controllers (or whatever), you depend on IDurableClientFactory clientFactory and execute clientFactory.CreateClient();

[nazar-kuzo]

@ltouro that looks as perfect solution, thanks for the quick reply!