Skip to content

Commit 382d824

Browse files
nzthiagonzthiago
committed
Addressing feedback and adding formula
1 parent 43fe910 commit 382d824

File tree

6 files changed

+54
-50
lines changed

6 files changed

+54
-50
lines changed

‎articles/azure-functions/event-driven-scaling.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -16,7 +16,7 @@ Function code files are stored on Azure Files shares on the function's main stor
1616

1717
## Runtime scaling
1818

19-
Azure Functions uses a component called the *scale controller* to monitor the rate of events and determine whether to scale out or scale in. The scale controller uses heuristics for each trigger type. For example, when you're using an Azure Queue storage trigger, it uses [target based scaling](functions-target-based-scaling.md).
19+
Azure Functions uses a component called the *scale controller* to monitor the rate of events and determine whether to scale out or scale in. The scale controller uses heuristics for each trigger type. For example, when you're using an Azure Queue storage trigger, it uses [target-based scaling](functions-target-based-scaling.md).
2020

2121
The unit of scale for Azure Functions is the function app. When the function app is scaled out, more resources are allocated to run multiple instances of the Azure Functions host. Conversely, as compute demand is reduced, the scale controller removes function host instances. The number of instances is eventually "scaled in" when no functions are running within a function app.
2222

@@ -32,7 +32,7 @@ Scaling can vary based on several factors, and apps scale differently based on t
3232

3333
* **Maximum instances:** A single function app only scales out to a [maximum allowed by the plan](functions-scale.md#scale). A single instance may process more than one message or request at a time though, so there isn't a set limit on number of concurrent executions. You can [specify a lower maximum](#limit-scale-out) to throttle scale as required.
3434
* **New instance rate:** For HTTP triggers, new instances are allocated, at most, once per second. For non-HTTP triggers, new instances are allocated, at most, once every 30 seconds. Scaling is faster when running in a [Premium plan](functions-premium-plan.md).
35-
* **Target Based Scaling:** Target Based Scaling provides a fast and intuitive scaling model for customers and is currently supported for Service Bus Queues and Topics, Storage Queues, Event Hubs, and Cosmos DB extensions. Make sure to review target based scaling to understand their scaling behavior.
35+
* **Target-based scaling:** Target-based scaling provides a fast and intuitive scaling model for customers and is currently supported for Service Bus Queues and Topics, Storage Queues, Event Hubs, and Cosmos DB extensions. Make sure to review target-based scaling to understand their scaling behavior.
3636

3737
## Limit scale-out
3838

‎articles/azure-functions/functions-bindings-cosmosdb-v2-trigger.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -14,7 +14,7 @@ The Azure Cosmos DB Trigger uses the [Azure Cosmos DB change feed](../cosmos-db/
1414

1515
For information on setup and configuration details, see the [overview](./functions-bindings-cosmosdb-v2.md).
1616

17-
Cosmos DB scaling decisions for the Consumption and Premium plans are done via Target Based Scaling. For more information, see [Target Based Scaling](functions-target-based-scaling.md).
17+
Cosmos DB scaling decisions for the Consumption and Premium plans are done via target-based scaling. For more information, see [Target-based scaling](functions-target-based-scaling.md).
1818

1919
::: zone pivot="programming-language-python"
2020
Azure Functions supports two programming models for Python. The way that you define your bindings depends on your chosen programming model.

‎articles/azure-functions/functions-bindings-service-bus-trigger.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -16,7 +16,7 @@ Starting with extension version 3.1.0, you can trigger on a session-enabled queu
1616

1717
For information on setup and configuration details, see the [overview](functions-bindings-service-bus.md).
1818

19-
Service Bus scaling decisions for the Consumption and Premium plans are done via Target Based Scaling. For more information, see [Target Based Scaling](functions-target-based-scaling.md).
19+
Service Bus scaling decisions for the Consumption and Premium plans are done via target-based scaling. For more information, see [Target-based scaling](functions-target-based-scaling.md).
2020

2121
::: zone pivot="programming-language-python"
2222
Azure Functions supports two programming models for Python. The way that you define your bindings depends on your chosen programming model.

‎articles/azure-functions/functions-bindings-storage-queue-trigger.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -12,7 +12,7 @@ zone_pivot_groups: programming-languages-set-functions-lang-workers
1212

1313
The queue storage trigger runs a function as messages are added to Azure Queue storage.
1414

15-
Azure Queue storage scaling decisions for the Consumption and Premium plans are done via Target Based Scaling. For more information, see [Target Based Scaling](functions-target-based-scaling.md).
15+
Azure Queue storage scaling decisions for the Consumption and Premium plans are done via target-based scaling. For more information, see [Target-based scaling](functions-target-based-scaling.md).
1616

1717
::: zone pivot="programming-language-python"
1818
Azure Functions supports two programming models for Python. The way that you define your bindings depends on your chosen programming model.

‎articles/azure-functions/functions-target-based-scaling.md

Lines changed: 49 additions & 45 deletions
Original file line numberDiff line numberDiff line change
@@ -1,34 +1,45 @@
11
---
2-
title: Target Based Scaling in Azure Functions
3-
description: Explains target based scaling behaviors of Consumption plan and Premium plan function apps.
2+
title: Target-based scaling in Azure Functions
3+
description: Explains target-based scaling behaviors of Consumption plan and Premium plan function apps.
44
ms.date: 04/04/2023
55
ms.topic: conceptual
66
ms.service: azure-functions
77

88
---
9-
# Target Based Scaling
9+
# Target-based scaling
1010

11-
Target Based Scaling provides a fast and intuitive scaling model for customers and is currently supported for the following extensions:
11+
Target-based scaling provides a fast and intuitive scaling model for customers and is currently supported for the following extensions:
1212

1313
- Service Bus Queues and Topics
1414
- Storage Queues
1515
- Event Hubs
1616
- Cosmos DB
1717

18-
Target Based Scaling replaces the previous incremental scaling model as the default for these extension types. Incremental scaling added or removed a maximum of 1 worker at [each new instance rate](event-driven-scaling.md#understanding-scaling-behaviors), with complex decisions for when to scale out and scale in. In contrast, Target Based Scaling allows scale up of 4 instances at a time, and the scaling decision is based on a simple target based equation:
18+
Target-based scaling replaces the previous Azure Functions incremental scaling model as the default for these extension types. Incremental scaling added or removed a maximum of 1 worker at [each new instance rate](event-driven-scaling.md#understanding-scaling-behaviors), with complex decisions for when to scale. In contrast, target-based scaling allows scale up of 4 instances at a time, and the scaling decision is based on a simple target-based equation:
1919

20-
$$ desiredWorkers = \lceil \frac{eventsourceLength}{targetExecutionsPerInstance} \rceil $$
20+
![Desired instances = event source length / target executions per instance](./media/functions-target-based-scaling/targetbasedscalingformula.png)
2121

22-
Target Based Scaling is supported for the [Consumption](consumption-plan.md) and [Premium](functions-premium-plan.md) plans. Your function app runtime must be 4.3.0 or higher.
22+
The default _target executions per instance_ values come from the SDKs used by the Azure Functions extensions. You don't need to make any changes for target-based scaling to work.
2323

2424
> [!NOTE]
25-
> In order to achieve the most accurate scaling based on metrics, we recommend one target based triggered function per function app.
25+
> In order to achieve the most accurate scaling based on metrics, we recommend one target-based triggered function per function app.
2626
27-
## Customizing Target Based Scaling
27+
## Prerequisites
2828

29-
The defaults are the same as set by the SDKs used by the Azure Functions extensions and you don't need to make any changes to your applications for Target Based Scaling to work. But to achieve a desired scale behavior for your app's workload, you can adjust _targetExecutionsPerInstance_ for each extension type. For example, Storage Queues use the `batchSize` defined in host.json as the _targetExecutionsPerInstance_.
29+
Target-based scaling is supported for the [Consumption](consumption-plan.md) and [Premium](functions-premium-plan.md) plans. Your function app runtime must be 4.3.0 or higher.
3030

31-
This table summarizes the `host.json` values that are used for target based scaling and the default values for each extension type:
31+
## Opting out
32+
Target-based scaling is on by default for apps on the Consumption plan or Premium plans without runtime scale monitoring. If you wish to disable target-based scaling and revert to incremental scaling, add the following app setting to your function app:
33+
34+
| App Setting | Value |
35+
| ----------------------------- | ----- |
36+
|`TARGET_BASED_SCALING_ENABLED` | 0 |
37+
38+
## Customizing target-based scaling
39+
40+
You can make the scaling behavior more or less aggressive based on your app's workload by adjusting _target executions per instance_. Each extension has different settings that you can use to set _target executions per instance_.
41+
42+
This table summarizes the `host.json` values that are used for the _target executions per instance_ values and the defaults:
3243

3344
| Extension | host.json values | Default Value |
3445
| -------------------------------------------------------------- | ----------------------------------------------------------------- | ------------- |
@@ -43,27 +54,46 @@ The defaults are the same as set by the SDKs used by the Azure Functions extensi
4354
| Event Hubs (if defined) | extensions.eventHubs.targetUnprocessedEventThreshold | n/a |
4455
| Storage Queue | extensions.queues.batchSize | 16 |
4556

46-
For the Cosmos DB extension, the target is set in the function attribute:
57+
For Cosmos DB _target executions per instance_ is set in the function attribute:
4758

4859
| Extension | Function trigger setting | Default Value |
4960
| ------------| ------------------------ | ------------- |
5061
| Cosmos DB | maxItemsPerInvocation | 100 |
5162

52-
The following section explains how to configure the target for each of the supported extensions.
63+
See [Details per extension](#details-per-extension) for example configurations of the supported extensions.
64+
65+
## Premium plan with runtime scale monitoring enabled
66+
In [runtime scale monitoring](functions-networking-options.md?tabs=azure-cli#premium-plan-with-virtual-network-triggers), the extensions handle target-based scaling. Hence, in addition to the function app runtime version requirement, your extension packages must meet the following minimum versions:
67+
68+
| Extension Name | Minimum Version Needed |
69+
| -------------- | ---------------------- |
70+
| Storage Queue | 5.1.0 |
71+
| Event Hubs | 5.2.0 |
72+
| Service Bus | 5.9.0 |
73+
| Cosmos DB | 4.1.0 |
74+
75+
Additionally, target-based scaling is currently an **opt-in** feature with runtime scale monitoring. In order to use target-based scaling with the Premium plan when runtime scale monitoring is enabled, add the following app setting to your function app:
76+
77+
| App Setting | Value |
78+
| ----------------------------- | ----- |
79+
|`TARGET_BASED_SCALING_ENABLED` | 1 |
80+
81+
## Dynamic concurrency support
82+
Target-based scaling introduces faster scaling, and uses defaults for _target executions per instance_. When using Service Bus or Storage queues you also have the option of enabling [dynamic concurrency](functions-concurrency.md#dynamic-concurrency). In this configuration, the _target executions per instance_ value is determined automatically by the dynamic concurrency feature. It starts with limited concurrency and identifies the best setting over time.
5383

54-
## Details per Extension
55-
### Service Bus Queues and Topics
84+
## Details per extension
85+
### Service Bus queues and topics
5686

5787
The Service Bus extension support three execution models, determined by the `IsBatched` and `IsSessionsEnabled` attributes of your Service Bus trigger. The default value for `IsBatched` and `IsSessionsEnabled` is `false`.
5888

59-
| | IsBatched | IsSessionsEnabled | Concurrency Setting Used for Target Based Scaling |
89+
| | IsBatched | IsSessionsEnabled | Concurrency Setting Used for target-based scaling |
6090
| ------------------------------------------ | --------- | ----------------- | ------------------------------------------------- |
6191
| Single Dispatch Processing | false | false | maxConcurrentCalls |
6292
| Single Dispatch Processing (Session Based) | false | true | maxConcurrentSessions |
6393
| Batch Processing | true | false | maxMessageBatchSize or maxMessageCount |
6494

6595
> [!NOTE]
66-
> **Scale efficiency:** For the Service Bus extension, use _Manage_ rights on resources for the most efficient scaling. With _Listen_ rights, scaling isn't as accurate because the queue length can't be used to inform scaling decisions. To learn more about setting rights in Service Bus access policies, see [Shared Access Authorization Policy](../service-bus-messaging/service-bus-sas.md#shared-access-authorization-policies).
96+
> **Scale efficiency:** For the Service Bus extension, use _Manage_ rights on resources for the most efficient scaling. With _Listen_ rights scaling will revert to incremental scale because the queue or topic length can't be used to inform scaling decisions. To learn more about setting rights in Service Bus access policies, see [Shared Access Authorization Policy](../service-bus-messaging/service-bus-sas.md#shared-access-authorization-policies).
6797
6898

6999
#### Single Dispatch Processing
@@ -149,7 +179,7 @@ For Functions host **v2.x+**, modify the `host.json` setting `maxMessageCount` i
149179
```
150180

151181
### Event Hubs
152-
For Event Hubs, Azure Functions scales based on the number of unprocessed events distributed across all the partitions in the hub. By default, the `host.json` attributes used are `maxEventBatchSize` and `maxBatchSize`. However, if you wish to fine-tune target based scaling, you can define a separate parameter `targetUnprocessedEventThreshold` that overrides the target value without changing the batch settings. If `targetUnprocessedEventThreshold` is set, the total unprocessed event count is divided by this value to determine the number of instances, which is then be rounded up to a worker instance count that creates a balanced partition distribution.
182+
For Event Hubs, Azure Functions scales based on the number of unprocessed events distributed across all the partitions in the hub. By default, the `host.json` attributes used are `maxEventBatchSize` and `maxBatchSize`. However, if you wish to fine-tune target-based scaling, you can define a separate parameter `targetUnprocessedEventThreshold` that overrides the target value without changing the batch settings. If `targetUnprocessedEventThreshold` is set, the total unprocessed event count is divided by this value to determine the number of instances, which is then be rounded up to a worker instance count that creates a balanced partition distribution.
153183

154184
> [!NOTE]
155185
> Since Event Hubs is a partitioned workload, the target instance count for Event Hubs is capped by the number of partitions in your Event Hub.
@@ -253,30 +283,4 @@ Sample `bindings` section of a `function.json` with `MaxItemsPerInvocation` defi
253283
}
254284
```
255285
> [!NOTE]
256-
> Since Cosmos DB is a partitioned workload, the target instance count for Cosmos DB is capped by the number of physical partitions in your Cosmos DB. For further documentation on Cosmos DB scaling, please see notes on [physical partitions](../cosmos-db/nosql/change-feed-processor.md#dynamic-scaling) and [lease ownership](../cosmos-db/nosql/change-feed-processor.md#dynamic-scaling).
257-
258-
## Opting Out
259-
Target Based Scaling is on by default for apps on the Consumption plan or Premium plans without Runtime Scale Monitoring. If you wish to disable Target Based Scaling and revert to incremental scaling, add the following app setting to your function app:
260-
261-
| App Setting | Value |
262-
| ----------------------------- | ----- |
263-
|`TARGET_BASED_SCALING_ENABLED` | 0 |
264-
265-
## Premium Plans with Runtime Scale Monitoring Enabled
266-
In [Runtime Scale Monitoring](functions-networking-options.md?tabs=azure-cli#premium-plan-with-virtual-network-triggers), the extensions handle Target Based Scaling. Hence, in addition to the function app runtime version requirement, your extension packages must meet the following minimum versions:
267-
268-
| Extension Name | Minimum Version Needed |
269-
| -------------- | ---------------------- |
270-
| Storage Queue | 5.1.0 |
271-
| Event Hubs | 5.2.0 |
272-
| Service Bus | 5.9.0 |
273-
| Cosmos DB | 4.1.0 |
274-
275-
Additionally, Target Based Scaling is currently an **opt-in** feature for this configuration. In order to use Target Based Scaling with the Premium plan when Runtime Scale Monitoring is enabled, add the following app setting to your function app:
276-
277-
| App Setting | Value |
278-
| ----------------------------- | ----- |
279-
|`TARGET_BASED_SCALING_ENABLED` | 1 |
280-
281-
## Dynamic Concurrency Support
282-
Target Based Scaling introduces faster scale out and in, and uses defaults for the targets. When using Service Bus or Storage queues with Target Based Scaling, you have the option of enabling [Dynamic Concurrency](functions-concurrency.md#dynamic-concurrency). In this configuration, the target metric is determined automatically by Dynamic Concurrency feature over time, instead of the `host.json` and function attributes.
286+
> Since Cosmos DB is a partitioned workload, the target instance count for Cosmos DB is capped by the number of physical partitions in your Cosmos DB. For further documentation on Cosmos DB scaling, please see notes on [physical partitions](../cosmos-db/nosql/change-feed-processor.md#dynamic-scaling) and [lease ownership](../cosmos-db/nosql/change-feed-processor.md#dynamic-scaling).

‎articles/azure-functions/media/functions-target-based-scaling/targetbasedscalingformula.png

10.6 KB
Loading

0 commit comments

Comments
 (0)