Introduction
With recent product improvements like Zero Downtime Slot Deployments and reworked workflow enumeration, Logic App Standard customers can now pack up to 1000 workflows together in a single app. Packing workflows together can simplify management of related workflows while reducing dedicated VM cost.
Handling post-deployment downtime
This section describes how increased workflow count affects deployment downtime – and how slot deployments help mitigate the resulting unavailability.
As workflow count increases in a logic app, deployment downtime becomes a primary blocker. By default, the logic apps runtime restarts after each deployment – each workflow is parsed, interpreted, and initialized. During this time, the runtime is unavailable (for example, request triggers will fail).
Host restarts become untenably long in many-workflow scenarios. This graph below shows restart times from an example logic app as 1000 workflows are deployed over a 30-minute period:
- Each blue line represents deploying a single new workflow.
- Each checkered purple line represents deploying 250 new workflows at once.
There are two takeaways:
- Initialization time has a ‘base cost’ depending on the number of existing workflows. Deploying a single workflow to an empty logic app will result in minimal downtime - but deploying the same workflow to a dense logic app (e.g. 500 existing workflows) can result in over 5 seconds of unavailability.
- Besides ‘base cost’, downtime can be high after cold starts or deploying many workflows at once.
As described in Enable deployment slots for zero downtime deployment, customers with ‘dense’ logic apps can now leverage slot deployments to mitigate this downtime. This allows such logic apps to remain available throughout deployment, regardless of workflow count.
Reworked workflow enumeration
In recent months, workflow enumeration from the Portal and VSCode has been reworked to better support high workflow counts. Beforehand, users could face long delays or fatal timeout errors if enumerating hundreds of workflows. This performance has been improved, particularly in portal – in general, we see over 10x speedup at the 50th percentile for such loads. Here is an example animation of a logic app with 1000 workflows:
This enables basic portal management of existing workflows (run history, resubmissions, etc) for these scenarios.
Limitations
While the portal ‘read-only’ experience is improved, customers editing workflows in the portal will still encounter a degraded development experience as the number of workflows increases. This is because host initialization performance is unchanged: each ‘save’ triggers a new deployment and restart – during this time, the runtime (and therefore portal experience) is unavailable.
