From 73b2582f529e7de96a0119a1d6c34f5646ac98c2 Mon Sep 17 00:00:00 2001 From: Whit Waldo Date: Thu, 9 May 2024 13:40:32 -0500 Subject: [PATCH] Added example for limiting workflow concurrency in .NET fan-in/out example (#4132) * Added workflow concurrency example for .NET Signed-off-by: Whit Waldo * Removed extension method that was doubling up calls and shortened to simpler inline example Signed-off-by: Whit Waldo * Removed unused extension method Signed-off-by: Whit Waldo * Neglected to include the Task.WhenAll line persisting the remaining result values Signed-off-by: Whit Waldo * Fixed parallism limit Signed-off-by: Whit Waldo * Adding proposed concluding thoughts Co-authored-by: Chris Gillum Signed-off-by: Whit Waldo * Approved proposed language Co-authored-by: Chris Gillum Signed-off-by: Whit Waldo --------- Signed-off-by: Whit Waldo Co-authored-by: Chris Gillum Co-authored-by: Hannah Hunter <94493363+hhunter-ms@users.noreply.github.com> Signed-off-by: salaboy --- .../workflow/workflow-patterns.md | 40 ++++++++++++++++++- 1 file changed, 39 insertions(+), 1 deletion(-) diff --git a/daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-patterns.md b/daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-patterns.md index f7865f55e9c..fe6f69b63c2 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-patterns.md +++ b/daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-patterns.md @@ -586,7 +586,45 @@ The key takeaways from this example are: - The number of parallel tasks can be static or dynamic - The workflow itself is capable of aggregating the results of parallel executions -While not shown in the example, it's possible to go further and limit the degree of concurrency using simple, language-specific constructs. Furthermore, the execution of the workflow is durable. If a workflow starts 100 parallel task executions and only 40 complete before the process crashes, the workflow restarts itself automatically and only schedules the remaining 60 tasks. +Furthermore, the execution of the workflow is durable. If a workflow starts 100 parallel task executions and only 40 complete before the process crashes, the workflow restarts itself automatically and only schedules the remaining 60 tasks. + +It's possible to go further and limit the degree of concurrency using simple, language-specific constructs. The sample code below illustrates how to restrict the degree of fan-out to just 5 concurrent activity executions: + +{{< tabs ".NET" >}} + +{{% codetab %}} + +```csharp + +//Revisiting the earlier example... +// Get a list of N work items to process in parallel. +object[] workBatch = await context.CallActivityAsync("GetWorkBatch", null); + +const int MaxParallelism = 5; +var results = new List(); +var inFlightTasks = new HashSet>(); +foreach(var workItem in workBatch) +{ + if (inFlightTasks.Count >= MaxParallelism) + { + var finishedTask = await Task.WhenAny(inFlightTasks); + results.Add(finishedTask.Result); + inFlightTasks.Remove(finishedTask); + } + + inFlightTasks.Add(context.CallActivityAsync("ProcessWorkItem", workItem)); +} +results.AddRange(await Task.WhenAll(inFlightTasks)); + +var sum = results.Sum(t => t); +await context.CallActivityAsync("PostResults", sum); +``` + +{{% /codetab %}} + +{{< /tabs >}} + +Limiting the degree of concurrency in this way can be useful for limiting contention against shared resources. For example, if the activities need to call into external resources that have their own concurrency limits, like a databases or external APIs, it can be useful to ensure that no more than a specified number of activities call that resource concurrently. ## Async HTTP APIs