Skip to content

Commit 5b814a0

Browse files
Merge pull request #271619 from ecfan/patch-1
Azure Logic Apps: Target-based scaling reverted to not being the default
2 parents 1e9f141 + b51fb9e commit 5b814a0

File tree

1 file changed

+6
-7
lines changed

1 file changed

+6
-7
lines changed

articles/logic-apps/target-based-scaling-standard.md

Lines changed: 6 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -5,7 +5,7 @@ services: logic-apps
55
ms.suite: integration
66
ms.reviewer: estfan, azla
77
ms.topic: conceptual
8-
ms.date: 01/29/2024
8+
ms.date: 04/09/2024
99
---
1010

1111
# Target-based scaling for Standard workflows in single-tenant Azure Logic Apps
@@ -18,19 +18,18 @@ For example, suppose you have a new app that takes off, so demand grows from a s
1818

1919
## How does scaling out differ from scaling up?
2020

21-
Scaling out versus scaling up focuses on the ways that scalability helps you adapt and handle the volume and array of data,
22-
changing data volumes, and shifting workload patterns. *Horizontal scaling*, which is scaling out or in, refers to when you add more databases or divide large database into smaller nodes by using a data partitioning approach called *sharding*, which you can manage faster and more easily across servers. *Vertical scaling*, which is scaling up or down, refers to when you increase or decrease computing power or databases as needed - either by changing performance levels or by using elastic database pools to automatically adjust to your workload demands. For more overview information about scalability, see [Scaling up vs. scaling out](https://azure.microsoft.com/resources/cloud-computing-dictionary/scaling-out-vs-scaling-up).
21+
Scaling out versus scaling up focuses on the ways that scalability helps you adapt and handle the volume and array of data, changing data volumes, and shifting workload patterns. *Horizontal scaling*, which is scaling out or in, refers to when you add more databases or divide large database into smaller nodes by using a data partitioning approach called *sharding*, which you can manage faster and more easily across servers. *Vertical scaling*, which is scaling up or down, refers to when you increase or decrease computing power or databases as needed - either by changing performance levels or by using elastic database pools to automatically adjust to your workload demands. For more overview information about scalability, see [Scaling up vs. scaling out](https://azure.microsoft.com/resources/cloud-computing-dictionary/scaling-out-vs-scaling-up).
2322

2423
## Scaling out and in at runtime
2524

26-
Single-tenant Azure Logic Apps currently uses a *target-based scaling* model to scale out or in, [similar to Azure Functions](../azure-functions/functions-target-based-scaling.md). This model is based on the target number of worker instances that you want to specify and provides a faster, simpler, and more intuitive scaling mechanism.
25+
Currently, single-tenant Azure Logic Apps uses an *incremental scaling model* that adds or removes a maximum of one worker instance for each [new instance rate](../azure-functions/event-driven-scaling.md#understanding-scaling-behaviors), and involves complex decisions that determine when to scale. The Azure Logic Apps scale monitor votes to scale up, scale down, or keep the current number of worker instances for your logic app, based on [*workflow job execution delays*](#workflow-job-execution-delay).
26+
27+
Azure Logic Apps also has the option to use a *target-based scaling* model to scale out or in, [similar to Azure Functions](../azure-functions/functions-target-based-scaling.md). This model is based on the target number of worker instances that you want to specify and provides a faster, simpler, and more intuitive scaling mechanism.
2728

2829
The following diagram shows the components in the runtime scaling architecture for single-tenant Azure Logic Apps:
2930

3031
:::image type="content" source="media/target-based-scaling-overview/runtime-scaling-architecture.png" alt-text="Architecture diagram shows runtime scaling components in Standard logic apps." lightbox="media/target-based-scaling-overview/runtime-scaling-architecture.png":::
3132

32-
Previously, Azure Logic Apps used an *incremental scaling model* that added or removed a maximum of one worker instance for each [new instance rate](../azure-functions/event-driven-scaling.md#understanding-scaling-behaviors) and also involved complex decisions that determined when to scale. The Azure Logic Apps scale monitor voted to scale up, scale down, or keep the current number of worker instances for your logic app, based on [*workflow job execution delays*](#workflow-job-execution-delay).
33-
3433
<a name="workflow-job-execution-delay"></a>
3534

3635
> [!NOTE]
@@ -42,7 +41,7 @@ Previously, Azure Logic Apps used an *incremental scaling model* that added or r
4241
> The scale monitor makes scaling decisions to keep the execution delays under control. For more
4342
> information about the runtime schedules and runs jobs, see [Azure Logic Apps Running Anywhere](https://techcommunity.microsoft.com/t5/azure-integration-services-blog/azure-logic-apps-running-anywhere-runtime-deep-dive/ba-p/1835564).
4443
45-
By comparison, target-based scaling lets you scale up to four worker instances at a time. The scale monitor calculates the desired number of worker instances required to process jobs across the job queues and returns this number to the scale controller, which helps make decisions about scaling. Also, the target-based scaling model also includes host settings that you can use to fine-tune the model's underlying dynamic scaling mechanism, which can result in faster scale-out and scale-in times. This capability lets you achieve higher throughput and reduced latency for fluctuating Standard logic app workloads.
44+
In comparison, target-based scaling lets you scale up to four worker instances at a time. The scale monitor calculates the desired number of worker instances required to process jobs across the job queues and returns this number to the scale controller, which helps make decisions about scaling. Also, the target-based scaling model also includes host settings that you can use to fine-tune the model's underlying dynamic scaling mechanism, which can result in faster scale-out and scale-in times. This capability lets you achieve higher throughput and reduced latency for fluctuating Standard logic app workloads.
4645

4746
The following diagram shows the sequence for how the scaling components interact in target-based scaling:
4847

0 commit comments

Comments
 (0)