Merge pull request #272540 from ecfan/revert-doc

Revert target-based scaling content

Author: v-shils

articles/logic-apps/.openpublishing.redirection.logic-apps.json

@@ -1,5 +1,10 @@
 {
     "redirections": [
+        {
+            "source_path_from_root": "/articles/logic-apps/target-based-scaling-standard.md",
+            "redirect_url": "/azure/logic-apps/logic-apps-limits-and-config?tabs=standard#scale-for-high-throughput",
+            "redirect_document_id": true
+        },
         {
             "source_path_from_root": "/articles/logic-apps/call-from-power-automate-power-apps.md",
             "redirect_url": "/azure/logic-apps/call-from-power-apps",

articles/logic-apps/edit-app-settings-host-settings.md

@@ -62,7 +62,6 @@ App settings in Azure Logic Apps work similarly to app settings in Azure Functio
 | `ServiceProviders.Sftp.SftpConnectionPoolSize` | `2` connections | Sets the number of connections that each processor can cache. The total number of connections that you can cache is *ProcessorCount* multiplied by the setting value. |
 | `ServiceProviders.MaximumAllowedTriggerStateSizeInKB` | `10` KB, which is ~1,000 files | Sets the trigger state entity size in kilobytes, which is proportional to the number of files in the monitored folder and is used to detect files. If the number of files exceeds 1,000, increase this value. |
 | `ServiceProviders.Sql.QueryTimeout` | `00:02:00` <br>(2 min) | Sets the request timeout value for SQL service provider operations. |
-| `TARGET_BASED_SCALING_ENABLED` | `1` | Sets Azure Logic Apps to use target-based scaling (`1`) or incremental scaling (`0`). By default, target-based scaling is automatically enabled. For more information see [Target-based scaling](#scaling). |
 | `WEBSITE_LOAD_ROOT_CERTIFICATES` | None | Sets the thumbprints for the root certificates to be trusted. |
 | `Workflows.Connection.AuthenticationAudience` | None | Sets the audience for authenticating a managed (Azure-hosted) connection. |
 | `Workflows.CustomHostName` | None | Sets the host name to use for workflow and input-output URLs, for example, "logic.contoso.com". For information to configure a custom DNS name, see [Map an existing custom DNS name to Azure App Service](../app-service/app-service-web-tutorial-custom-domain.md) and [Secure a custom DNS name with a TLS/SSL binding in Azure App Service](../app-service/configure-ssl-bindings.md). |
@@ -184,93 +183,6 @@ The following example shows the syntax for these settings where each workflow ID
 "Jobs.SuspendedJobPartitionPrefixes": "<workflow-ID-1>:; <workflow-ID-2>:"
 ```
 
-<a name="scaling"></a>
-
-### Target-based scaling
-
-Single-tenant Azure Logic Apps gives you the option to select your preferred compute resources and set up your logic app resources to dynamically scale based on varying workload demands. The target-based scaling model used by Azure Logic Apps includes 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. For more information about the target-based scaling model, see [Target-based scaling for Standard workflows in single-tenant Azure Logic Apps](target-based-scaling-standard.md).
-
-#### Considerations
-
-- Target-based scaling isn't available or supported for Standard workflows running on an App Service Environment or Consumption plan.
-
-- If you have scale-in requests without any scale-out requests, Azure Logic Apps uses the maximum scale-in value. Target-based scaling can scale down unused worker instances faster, resulting in more efficient resource usage.
-
-#### Requirements
-
-- Your logic apps must use [Azure Functions runtime version 4.3.0 or later](../azure-functions/set-runtime-version.md).
-
-- Your logic app workflows must use single-tenant Azure Logic Apps runtime version 1.55.1 or later.
-
-#### Target-based scaling settings in host.json
-
-| Setting | Default value | Description |
-|---------|---------------|-------------|
-| `Runtime.TargetScaler.TargetConcurrency` | `null` | The number of target executions per worker instance. By default, the value is `null`. If you leave this value unchanged, your logic app defaults to using dynamic concurrency. You can set a targeted maximum value for concurrent job polling by using this setting. For an example, see the section following this table. |
-| `Runtime.TargetScaler.TargetScalingCPU` | `70` | The maximum percentage of CPU usage that you expect at target concurrency. You can change this default percentage for each logic app by using this setting. For an example, see the section following this table. |
-| `Runtime.TargetScaler.TargetScalingFactor` | `0.3` | A numerical value from `0.05` to `1.0` that determines the degree of scaling intensity. A higher target scaling factor results in more aggressive scaling. A lower target scaling factor results in more conservative scaling. You can fine-tune the target scaling factor for each logic app by using this setting. For an example, see the section following this table. |
-
-##### TargetConcurrency example
-
-```json
-{
-   "version": "2.0",
-   "extensionBundle": {
-      "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows",
-      "version": "[1.*, 2.0.0)"
-   },
-   "extensions": {
-      "workflow": {
-         "Settings": {
-            "Runtime.TargetScaler.TargetConcurrency": "280"
-         }
-      }
-   }
-}
-```
-
-#### TargetScalingCPU example
-
-```json
-{
-   "version": "2.0",
-   "extensionBundle": {
-      "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows",
-      "version": "[1.*, 2.0.0)"
-   },
-   "extensions": {
-      "workflow": {
-         "Settings": {
-            "Runtime.TargetScaler.TargetScalingCPU": "76"
-         }
-      }
-   }
-}
-```
-
-##### TargetScalingFactor example
-
-```json
-{
-   "version": "2.0",
-   "extensionBundle": {
-      "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows",
-      "version": "[1.*, 2.0.0)"
-   },
-   "extensions": {
-      "workflow": {
-         "Settings": {
-            "Runtime.TargetScaler.TargetScalingFactor": "0.62"
-         }
-      }
-   }
-}
-```
-
-#### Disable target-based scaling
-
-By default, target-based scaling is automatically enabled. To opt out from using target-based scaling and revert back to incremental scaling, add the app setting named **TARGET_BASED_SCALING_ENABLED** and set the value set to **0** in your Standard logic app resource using the Azure portal or in your logic app project's **local.settings.json file** using Visual Studio Code. For more information, see [Manage app settings - local.settings.json](#manage-app-settings).
-
 <a name="recurrence-triggers"></a>
 
 ### Recurrence-based triggers

articles/logic-apps/logic-apps-limits-and-config.md

@@ -179,7 +179,7 @@ The following table lists the values for an **Until** loop:
 The following table lists the values for a single workflow definition:
 
 | Name | Multitenant | Single-tenant | Notes |
-|------|--------------|---------------|-------|
+|------|-------------|---------------|-------|
 | Action - Executions per 5-minute rolling interval | Default: 100,000 executions <br>- High throughput mode: 300,000 executions | None | In multitenant Azure Logic Apps, you can raise the default value to the maximum value for your workflow. For more information, see [Run in high throughput mode](#run-high-throughput-mode), which is in preview. Or, you can [distribute the workload across more than one workflow](handle-throttling-problems-429-errors.md#logic-app-throttling) as necessary. |
 | Action - Concurrent outbound calls | ~2,500 calls | None | You can reduce the number of concurrent requests or reduce the duration as necessary. |
 | Managed connector throttling | Throttling limit varies based on connector | Throttling limit varies based on connector | For multitenant, review [each managed connector's technical reference page](/connectors/connector-reference/connector-reference-logicapps-connectors). <br><br>For more information about handling connector throttling, review [Handle throttling problems ("429 - Too many requests" errors)](handle-throttling-problems-429-errors.md#connector-throttling). |
@@ -194,21 +194,30 @@ The following table lists the values for a single workflow definition:
 
 ### [Standard](#tab/standard)
 
-Single-tenant Azure Logic Apps uses storage and compute as the primary resources to run your Standard logic app workflows.
+In single-tenant Azure Logic Apps, a Standard logic app resource uses storage and compute as the primary resources to run workflows.
 
 ### Storage
 
-Stateful workflows use Azure Table storage and Azure Blob storage for persistenting data storage during runtime and for maintaining run histories. These workflows also use Azure Queues for scheduling. A single storage account enables a substantial number of requests with rates of up to 2K per partition and 20K requests per second at the account level. Beyond these thresholds, request rates are subject to throttling. For storage scalability limits, see [Targets for data operations](../storage/tables/storage-performance-checklist.md#targets-for-data-operations).
+Stateful workflows in single-tenant Azure Logic Apps use Azure Table Storage for persistent data storage during runtime, Azure Blob Storage for maintaining workflow run histories, and Azure Queue Storage for scheduling purposes. For example, a single storage account enables handling a substantial number of requests with rates of up to 2,000 requests per partition and 20,000 requests per second at the storage account level. While a single storage account can handle reasonably high throughput, beyond these thresholds, request rates are subject to throttling, and your workflows might experience partition level throttling or account level throttling as workflow execution rate increases. To make sure that your workflows operate smoothly, it's crucial that you understand the possible limitations and the ways that you can address them.
+
+For more information about scaling targets and limitations for the various Azure Storage services, see the following documentation:
+
+- [Scale targets for Table Storage](../storage/tables/scalability-targets.md#scale-targets-for-table-storage)
+- [Data operation targets for Table Storage](../storage/tables/storage-performance-checklist.md#targets-for-data-operations)
+- [Scale targets for Blob Storage](../storage/blobs/scalability-targets.md#scale-targets-for-blob-storage)
+- [Scale targets for Queue Storage](../storage/queues/scalability-targets.md#scale-targets-for-queue-storage)
+
+#### Scale your logic app for storage limitations
 
-Although a single storage account can handle reasonably high throughput, as the workflow execution rate increases, you might encounter partition level throttling or account level throttling. To ensure smooth operations, make sure that you understand the possible limitations and ways that you can address them.
+The following recommendations apply to scaling Standard logic app workflows:
 
-##### Share workload across multiple workflows
+- Share workload across multiple workflows.
 
-Single-tenant Azure Logic Apps minimizes partition level throttling by distributing storage transactions across multiple partitions. However, to improve distribution and mitigate partition level throttling, [distribute the workload across multiple workflows](handle-throttling-problems-429-errors.md#logic-app-throttling), rather than a single workflow.
+  Single-tenant Azure Logic Apps already minimizes partition-level throttling by distributing storage transactions across multiple partitions. However, to improve distribution and mitigate partition-level throttling, [distribute the workload across multiple workflows](handle-throttling-problems-429-errors.md#logic-app-throttling), rather than rely on a single workflow.
 
-##### Share workload across multiple storage accounts
+- Share workload across multiple storage accounts.
 
-  If your logic app's workflows require high throughput, use multiple storage accounts, rather than a single account. You can significantly increase throughput by distributing your logic app's workload across multiple storage accounts with 32 as the limit. To determine the number of storage accounts that you need, use the general guideline for ~100,000 action executions per minute, per storage account. While this estimate works well for most scenarios, the number of actions might be lower if your workflow actions are compute heavy, for example, a query action that processes large data arrays. Make sure that you perform load testing and tune your solution before using in production.
+  If your workflows require high throughput, you can significantly increase throughput by distributing the workload across multiple storage accounts, rather than rely on a single storage account. You can set up your Standard logic app resource to use up to 32 storage accounts as the limit. To determine the number of storage accounts that you need, use the general guideline of aiming for ~100,000 action executions per minute, per storage account. While this estimate works well for most scenarios, you might use a lower number of action executions if your workflow actions are compute heavy, for example, a query action that processes large data arrays. Make sure that you perform load testing and tune your solution before using in production.
 
   To enable using multiple storage accounts, follow these steps before you create your Standard logic app. Otherwise, if you change the settings after creation, you might experience data loss or not achieve the necessary scalability.